Re: globals besides relvars?

"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?

"goes into" implies physicality. The relational model demands that users manipulate globally accessible data only as relvars, but this says nothing about how or where anything actually gets stored.

> So what if you have some function that requires some storage?

No 'function' requires global state information.

> For example, imagine a function that returns the current timezone.

Your problem is imagining that this simple datum is a function.

> It needs to store this somewhere.

One would represent the datum as a value in a global relvar, and one has no need for a function.

> Presumably there's a setTimeZone
> function also.

You presume incorrectly. There is a timezone attribute in a global relvar with an empty candidate key.

> Where does it store the timezone?

We don't care. How it represents the datum matters. Where it stores it does not matter at all.

> Is it allowable
> to have a storage that's bound to a function in the catalog, perhaps?

As long as the binding is only for performance and is not logically exposed to the user in any way, anything goes.

> But if this is allowed, isn't it starting to sound like objects?

Objects require tightly bound storage. Relations allow it. There is a big difference.

> (behavior + state, eh?)

Since the physical storage is not exposed to the user, there is no measurable state. Logically, a function is pure behaviour.

> 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.

The identity value for an operator exists even if one doesn't store it. Received on Mon Jul 28 2003 - 16:45:21 CEST