Re: no names allowed, we serve types only

From: Bob Badour <>
Date: Mon, 15 Feb 2010 10:30:48 -0400
Message-ID: <4b795a9d$0$12441$>

Keith H Duggar wrote:

> On Feb 14, 2:38 pm, r..._at_raampje.lan (Reinier Post) wrote:

>>Keith H Duggar wrote:
>>>You think my proposal does not allow you to uniquely address header
>>>attributes? I think you need to try again, perhaps with less of a
>>>focus on "telling us" what sets and ordered pairs are.
>>Perhaps it would help if you explain what a 'copied type' is

> I was hoping I could get away with just a loose intuitive notion for
> what it is ;-) If X is a typecopy of Y then X and Y are distinct types
> that are mutually coercible and whose extensions are equal. If need be
> we can go into much more detail. However, if possible I'd like to
> focus on what usefulness names add other than to handle attributes
> with the same type?
> For example, just for the sake of argument, pretend we are working
> in a universe where every attribute of a relation always has a unique
> type in that relation. Ie just pretend that there is never a case
> where
> we want to have two or more attributes in the same relation having the
> same type. Now, in this world do we gain anything any usefulness at
> all by having attribute names?

Yes. We gain control over natural join.

>>and how 'copying types' is more convenient than ordering
>>or naming different attributes with the same type.

> I don't know whether it necessarily more convenient but I do believe
> it simplifies the relational model. For one, it is often the case that
> one already has unique types and thus can already construct a header
> without the additional "attribute names". Second, requiring unique
> types and reducing the header to a simple set eliminates the need to
> define an additional uniqueness constraint across <name,type> pairs.

But you haven't really done that. Your "copy" declaration must still track the underlying type. Received on Mon Feb 15 2010 - 15:30:48 CET

Original text of this message