Re: globals besides relvars?

From: Paul Vernon <paul.vernon_at_ukk.ibmm.comm>
Date: Mon, 28 Jul 2003 18:37:40 +0100
Message-ID: <bg3n62$hoc$1_at_gazette.almaden.ibm.com>


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

So what? Programming languages have many things that we we don't need. 'Functions' that access global data being just one of them.

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

Because that's all we're got. Luckily, it's all we need as well. :-)

> I mean, the current timezone
> is not a relation, it's a value from the timezone domain. Current user is a
> string or a User value or something. It's not a relation. So why must it go
> into a relation? I'm already aware that Codd so asserted, but I don't
> see any good theoretical or even a good design reason for it.

Good design: don't distinguish things unnecessarily.

> Worse, if I make a relvar Timezone, I can issue nonsensical updates
> to it. What does it mean to insert into Timezone? 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. That's what you get if you make Timezone a global
> *non-relation* variable.

Having *non-relation* variables makes the whole environment (much) more complex, for no benefit. Information is no longer democratic. Why should Timezone get special treatment and not, current bank balance or last update statement or current query optimisation level??

> > > 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
>
> Um, that's not the same thing. It's not even clear what the
> above means for a binary operator.

Using some brain dead SQL...

with add(a,b,X) AS
(values (0,0,0)

, (1,0,1)
, (0,1,1)
, (2,0,2)
, (1,1,2)
, (0,2,2)
, (3,0,3)
, (2,1,3)
, (1,2,3)
, (0,3,3)

)
SELECT DISTINCT B c1
FROM add
WHERE A = X
GROUP BY B
HAVING COUNT(*) = (
    SELECT COUNT(DISTINCT B) c1
    FROM add
)
UNION
SELECT DISTINCT A c1
FROM add
WHERE B = X
GROUP BY A
HAVING COUNT(*) = (
    SELECT COUNT(DISTINCT A) c1
    FROM add
)
;

> In any event, the above
> might require infinite time to return.

Not infinite as our machines are not infinite. Might take a long time, depends on the physical impementaion.

Anyhow I might allow such identities to be declared as constraints on the function literals. They would be logically redundant, but might be nice nonetheless. All the usual functional properties - association etc could be declared this way.

> I'm talking about the fact that some functions (in the pure
> mathematical sense) have associated "identity" values.
> That is, for all x, there exists a value id such that
> x op id = x.
>
> It makes sense to me to consider this constant value
> as being visible in some places.

Agreed, and constraints on function literals is my suggestion.

> There are advantages
> to being able to query the op to see if it has an identity,
> and what the value is.

Agreed, and with my suggestion you don't need any sepecial operators, just our good old relational operations.

P.S. Functions can have more that one idenity value.

Regards
Paul Vernon
Business Intelligence, IBM Global Services Received on Mon Jul 28 2003 - 19:37:40 CEST

Original text of this message