Re: globals besides relvars?
Date: Mon, 28 Jul 2003 14:03:11 +0100
Yes. The Information Principle.
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 and current USER.
> 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
Business Intelligence, IBM Global Services Received on Mon Jul 28 2003 - 15:03:11 CEST