Re: no names allowed, we serve types only

On Feb 20, 5:30 am, Keith H Duggar <dug..._at_alum.mit.edu> wrote:

> Thanks David for putting meat on the bones! Indeed this is
> exactly the direction I was thinking of. I'd never run into
> the "Universal Relation" idea and need to look into that.
> Do you happen to have any of the better references you
> found handy?

Start with a thread "Navigation vs Relational operators" on cdt back in May 2004. D Guntermann provided some links. Jan's link to an online  presentation still works.

> Yes precisely. A rich type system can provide conveniences such
> as that. In addition, though the equality operator is the primary
> concern above, a type system can provide fine grained control of
> explicit/implicit coersion by allowing one to add and remove
> individual function signatures from the explicit/implicit set.
>
> We can also use inline explicit casts just as one would might
> use rename in a join for attribute names. So for the L=D above
> in they are declared as explicit coersion then one could write
> CITYNAME(L)=CITYNAME(D) which is very similar to some of Date's
> casting examples here and there.
>
> > Admittedly, SUPPLIERDISPATCHCITY seems quite verbose for a type name -
> > but perhaps that's just based on us having put up with (attribute
> > name, simple type) pairings for so long.
>
> Right, it's probably not any more verbose than the pair taken
> as whole.

Is that true in general? I think there will be a tendency for both the relation name (e.g. "SUPPLIER") and the attribute name (e.g. "LOCATION") to be merged with the attribute type (e.g. "CITY"). Received on Sat Feb 20 2010 - 04:45:42 CET