Re: Relation name = address?

From: Bob Badour <bbadour_at_pei.sympatico.ca>
Date: Thu, 18 May 2006 18:11:13 GMT
Message-ID: <5N2bg.9435$A26.235584_at_ursa-nb00s0.nbnet.nb.ca>


JOG wrote:

> Is a relation's 'name' in fact a pointer? Relation names obviously
> don't come under the remit of the information principle, yet they are
> essential to database manipulation and querying. Are they hence an
> acceptable/necessary exception?

In the sense that a relvar name points to something one can change with imperative statements, yes, it is a pointer. In the sense that the thing one can change might be derived from many other things, no, it is not a pointer.

The name is unquestionably an identifier. If one considers address synonymous with identifier, then it is an address. But I do not consider them synonymous. All addresses are identifiers. Not all identifiers are addresses.

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

I think you are mixing things that do not mix. In the grammar of a language, use of a variable name is a dereferencing production no matter what language one considers. In a system catalog, the name is a value related to other values by the relation variables in the catalog.

To generate addressing/dereferencing, one would have to extend the language to support name substitutions from queries in queries. In other words, you would have to introduce some generic programming constructs. Received on Thu May 18 2006 - 20:11:13 CEST

Original text of this message