Re: globals besides relvars?

"Marshall Spight" <mspight_at_dnai.com> wrote in message news:S%bVa.149598$wk6.37711_at_rwcrnsc52.ops.asp.att.net...
> "Paul Vernon" <paul.vernon_at_ukk.ibmm.comm> wrote in message
news:bg373c$16i2$1_at_gazette.almaden.ibm.com...
> > "Marshall Spight" <mspight_at_dnai.com> wrote in message
> > news:eX0Va.143552$GL4.37155_at_rwcrnsc53...
> >
> > > 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.
>
> This is true for functions in the strict mathematical sense, but in
> most programming languages, functions have access to global
> data. In many programming languages, functions have access to
> function-local state as well.

I can only think of one function that ordinarily requires access to some kind of global data, and one could just as easily replace this function with a value in a relvar.

> > > 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.
>
> "A function" is a perfectly good name for "a value of some relvar."
> (Well, a part of a relvar, anyway.) It more typically refers to some
> code, but the above still works.
>
>
> > 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.
>
> Okay, but why do these things have to be relvars? I mean, the current
timezone
> is not a relation, it's a value from the timezone domain.

Nobody said it has to be a relation. It is a value in a relation. All values in relations are values from one domain or another.

> Current user is a
> string or a User value or something. It's not a relation. So why must it
go
> into a relation?

So that we can directly apply logic for its management.

> I'm already aware that Codd so asserted, but I don't
> see any good theoretical or even a good design reason for it.

You don't see any good theoretical use for requiring a representation whereby one can use logic directly?

> Worse, if I make a relvar Timezone, I can issue nonsensical updates
> to it. What does it mean to insert into Timezone?

You presuppose a nonsensical relvar. Why should subsequent nonsense surprise or alarm anyone? It's just a straw man.

> Okay, so maybe
> you say the fact that I have a no-columns key for the table makes
> that insert fail. Or there's some kind of constraint that prevents
> a delete from succeeding. But it would be better if the structure
> made it the case that these nonsensical updates weren't even
> expressible.

Don't use a TimeZone relvar--use a sensible relvar instead.

> That's what you get if you make Timezone a global
> *non-relation* variable.

A global non-relation TimeZone variable is just as nonsensical as the relvar you propose above. If one allows the global distribution of a database (and I see no reason to prohibit distribution), the database does not have single, distinct time zone. Received on Mon Jul 28 2003 - 21:07:24 CEST