<martin.bowes (AT) ctsu (DOT) ox.ac.uk> wrote

And that assumes you have just one production installation to test for.
What if you want to deploy in Intel, SPARC, PowerPC, and Alpha? You can't
just assume the same code works OK on all of them. Heck, it probably won't
even compile on all of them.

25 years ago I was writing code for network databases. It was often a slow
and grinding misery and I yearned for a set of intelligent templates (we'd
probably call them wizards today). That was as imaginative as I got. It
never occurred to me that a non-procedural language would be even better.
Then one day I found Ingres and QUEL, and suddenly I was orders of magnitude
more productive! Talk about a religious experience! (Younger members of
the audience can substitute SQL for "QUEL" above.)

We've never had a product with proper user-defined types. We conceive our
designs in terms of what we know we have to work with--the 1950s data types.
That sets our expectations. We are as content as cows in a field. Or else
we are at the other extreme, get the problem backwards, and announce that
"the relational model" is too feeble for the demands of modern applications.
All those dim-bulbs out there enthusing foolishly about XML "databases" and
OODBMSs think they have a more powerful model because they've got better
data types. (If even that much is true, then that is all they've got. But
that is another rant for another time.)

But to repeat, this is NOT the topic of my IUA presentation next month.

Me for one.

You probably aren't evil enough, although that takes some believing...

The Postgres/PostgreSQL people have done a lot with it. I don't know too
much about it. I am willing to bet there've been more than a few problems
with it, based on the little I do know. Another intriguing enterprise is
FirstSQL; you can Google for that one. I have a few gripes about FirstSQL,
but it gets a whole lot more right than most such endeavours.

Roy

At 3:19 PM +0100 9/20/05, Roy Hann wrote:
Now, now. Writing portable code isn't hard.

Although I suppose it helps to have gotten burned a few times first.

Karl

"Betty & Karl Schendel" <schendel (AT) kbcomputer (DOT) com> wrote

It's just software. How hard could it be? :-)

Rex Jaeschke published a very fine book years ago, on writing portable C
code. I found it extremely helpful when I was more concerned about such
things. I suspect it is looooooong out of print though.

Roy

I'm on "holiday" at the moment, so I've been following this at a distance, and will commit the cardinal sin of replying to multiple posts at once ...

martin.bowes (AT) ctsu (DOT) ox.ac.uk (amongst others) wrote:

Hmmm...... (I'm getting my Donald Rumsfeld impersonation ready...)

I think Mike and I kicked SQLJ around a while ago, and agreed to disagree. Reading the proposed SQL standard for SQLJ made me think "too much is not enough, already".

This sort of stuff is readily do-able, but it needs a fair bit of architecting under the covers to make it work, and make it work properly.

Now, I am ready for a fight on this one, which we can have tomorrow (Maybe I should email a reminder about the SIUA, with a UDT bout as the lunchtime attraction

The central assertion is: if your database is a set of assertions of facts about things, best make sure you're talking about the right things.

Consider (as the example put forward for the presentation Roy and I gave) the case of the Scottish Candidate Number. Looks like an integer, smells like an integer, but it sure doesn't walk like an integer - so why should I be stuck with representing them as integers ? Consider the code ...

declare scn = integer;
begin
// some random stuff here
scn = scn + 1;
// some more bumph
end

No compiler, no logic system, no type inference system in the world can get past the fact that you've just made a total boo-boo - the last digit of an SCN is a check digit, so the operation "+ 1" should not be permitted on SCNs. Essentially, the type system has forced us into, and actively colluded in, perpetrating garbage.

This is about the most trivial example I can think of. Really, the whole idea of overloading integers to mean multiple things should have been thrown out when Pascal introduced enumerations back in 1968. That Niklaus Wirth eventually dumped them when he built Oberon-2 (the object oriented extension to Modula-2), because they introduced inconsistencies in scoping and made the compiler more difficult (take your pick, he used both justifications and I know which one I really believe), merely killed the whole object oriented myth stone-dead for me.

User defined functions are, to my mind, a subset of user defined types. Introducing a new type involves introducing new operators or functions to deal with those new types. It's rare that we really want to add new operators to integers, say, compared to the number of times we should be defining new, useful types.

I doubt it. It's a, shall we say, non-trivial task. PostgreSQL started from the position that user defined types (and indeed, user defined indexing) were going to be aggressively pursued, so a certain amount of substructure was built to handle it. I'm not sure Ingres is quite so amenable, and (sorry Karl) my heart sinks when I think about meandering through the Ingres source code. I'm just too used to dealing with Prolog and Haskell nowadays, and C just breaks my poor ole heart...

- Tony


__________________________________________________ ________________
Switch to Netscape Internet Service.
As low as $9.95 a month -- Sign up today at http://isp.netscape.com/register

Netscape. Just the Net You Need.

New! Netscape Toolbar for Internet Explorer
Search from anywhere on the Web and block those annoying pop-ups.
Download now at http://channels.netscape.com/ns/search/install.jsp