Re: [Info-ingres] Re: UK IUA agenda?
- From: Tonyd08068@xxxxxxxxxxxx
- Date: Wed, 21 Sep 2005 07:25:52 -0400
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@xxxxxxxxxxxxx (amongst others) wrote:
>> What makes you think that? Am I *so* unreasonable? :-) Or perhaps you
>> were thinking of Tony; yes, there you may get an argument.
Hmmm...... (I'm getting my Donald Rumsfeld impersonation ready...)
>> > We REALLY need SQLJ extensions for Ingres. This would allow
>> > - much safer and easier OME functionality
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".
> I'm all for safety by encapsulating the user changes, but I'm at
>a loss to see how this could be done. But I'm not that smart. I just read
>the OME manual and took the comment about thoroughly testing the
>code on a test installation before installing on a production box *VERY*
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.
> Another point would be - are we jumping at shadows. Hands up
>everyone who has actually found a need for a UDT. I would bet the
>answer is very, very few people. I think the '1950s datatypes' as
>Rampaging Roy Hann calls them will satisfy the vast majority of us.
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;
// some random stuff here
scn = scn + 1;
// some more bumph
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.
> As a guess - and pure guesswork on this - I suspect that user
>defined functions would be more common.
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 think an improved version
>of soundex, or an equivalent function has been mentioned by a few.
>Ditto a regex function - which is what I'm currently tinkering my way
>towards. Hey, I havent even made a function that returns the integer 5
>yet. I'm not a good programmer, that's why I went into DBA.
> As an aside - are people tackling this sort of extended
>functionality in OpenSource?
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...
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
- Prev by Date: RE: [Info-ingres] Ingres/ICE (3.0.2) and Apache 2.0.54
- Next by Date: copydb: interger overflow error
- Previous by thread: Re: [Info-ingres] Re: UK IUA agenda?
- Next by thread: Problems with using the like clause