Re: Relation name = address?

JOG wrote:
> Is a relation's 'name' in fact a pointer?

A name is just an abstraction for a value (or expression, or even a variable, or whatever.)

> Relation names obviously
> don't come under the remit of the information principle, yet they are
> essential to database manipulation and querying.

They actually aren't essential to querying. In a language that treats relations as first-class values, there's no reason why you couldn't, say, select-and-project using a relation literal as a source. This shows that while useful (to the point of being mandatory) names are largely incidental.

As far as manipulation goes, the situation is less clear cut, but I believe the same answer results. There are languages in which variables are first class languages constructs. (One could say OOP works this way, but that's not quite what I mean.)

> Are they hence an
> acceptable/necessary exception?

I don't think they're an exception. Instead, I think they are best considered as the simplest, most fundamental abstraction facility.

This brings up something that I've been thinking about lately, which is that most of our discussions about language semantics largely ignore the highly important issue of abstraction facilities.

> In TTM's cogent discussion of OID's Date & Darwin talk about "a
> database relvar might reasonably have an attribute whose values are
> (say) ... 'database relvar names'". This strikes as possibly generating
> a form of addressing/dereferencing procedure. Jim.

Yes, although note that this then introduces questions about the difference between compile time and runtime, which is another issue we rarely touch on.

Marshall Received on Fri May 19 2006 - 09:13:28 CEST