Re: globals besides relvars?
Date: Mon, 28 Jul 2003 14:03:11 +0100
Message-ID: <bg373c$16i2$1_at_gazette.almaden.ibm.com>
"Marshall Spight" <mspight_at_dnai.com> wrote in message
news:eX0Va.143552$GL4.37155_at_rwcrnsc53...
> There's this idea that global data only goes into relvars, right?
Yes. The Information Principle.
> So what if you have some function that requires some storage?
No such thing. Functions take values, do some computation on those values, and return some other values. They don't store values (at least not ones that change), that is what assignment is for.
> For example, imagine a function that returns the current timezone.
> It needs to store this somewhere.
current timezone is not a function. It is just a value of some relvar.
Same goes for all of the SQL 'special registers'. By which I mean, in a truly
relational dbms, there would not be any special registers, or functions that store
values. Such things would violate the information principle
IMO A good catalog model would include relvars to holds things like current timestamp
> Presumably there's a setTimeZone
> function also.
Nope, just update the relvar that holds that info (for a User, Session, Location or whatever)
>Where does it store the timezone? Is it allowable
> to have a storage that's bound to a function in the catalog, perhaps?
>
> But if this is allowed, isn't it starting to sound like objects?
> (behavior + state, eh?)
Yes, and that should tell you that you're barking up the wrong tree.
> Earlier I was thinking about operator identity. (The + operator
> has zero as the identity value; multiply has 1.) This seems
> like it associates with a function as well. But this idea doesn't
> seem so problematic, because it's just a constant.
something as simple as this
SELECT * FROM FUNCTION_LITERAL
WHERE IN_VALUE = OUT_VALUE
would return you all the identity mappings of a function
Regards
Paul Vernon
Business Intelligence, IBM Global Services
Received on Mon Jul 28 2003 - 15:03:11 CEST