Re: Dreaming About Redesigning SQL

From: Jan Hidders <jan.hidders_at_REMOVETHIS.pandora.be>
Date: Fri, 10 Oct 2003 23:09:53 GMT
Message-ID: <5%Ghb.70458$rt6.3541092@phobos.telenet-ops.be>

Paul G. Brown wrote:
> Jan Hidders <jan.hidders_at_pandora.be.REMOVE.THIS> wrote in message news:<3f851baa.0_at_news.ruca.ua.ac.be>...

>>
>>Er, well, file names are actually not abstract because they have a 
>>concrete representation that you can read.

>
> We could go round and round on this. I'd observe that there is a whole
> class of things which can potentially go into tuple attributes that aren't
> 'values': for example, you might put a query in there,

A query is a value.

> or a reference,

A reference, just by itself without some magical DEREF funcion is an (abstract) value.

> or a filename,

A filename is a value.

> or an executable script to generate a value.

A script is a value.

> The information content of such values are always 'one step removed' from their
> representation, and may in fact be ambiguous.

That you can do an extra step to derive some more information doesn't mean that they didn't already have some information to begin with. The crucial question is if in this extra step you need some extra information that is not to be found anywhere in the tables. For the evaluation of the query you don't. For dereferencing the reference without the help of a table that associates them with their destination, you do. For looking up the contents of the file without the help of a table that associates them with their contents, you do. For executing the script you don't.

So as long as you don't expect a DEREF function or a function that magically looks up the content of a file none of you examples violates the information principle.

Jan Hidders

Received on Fri Oct 10 2003 - 18:09:53 CDT