Re: globals besides relvars?

From: Paul Vernon <paul.vernon_at_ukk.ibmm.comm>
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 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

Regards
Paul Vernon
Business Intelligence, IBM Global Services Received on Mon Jul 28 2003 - 15:03:11 CEST

Original text of this message