Re: Why don't we support external input/output functions for the composite types - Mailing list pgsql-hackers

From Tom Lane
Subject Re: Why don't we support external input/output functions for the composite types
Date
Msg-id 3546.1714155944@sss.pgh.pa.us
Whole thread Raw
In response to Re: Why don't we support external input/output functions for the composite types  (Robert Haas <robertmhaas@gmail.com>)
Responses Re: Why don't we support external input/output functions for the composite types
List pgsql-hackers
Robert Haas <robertmhaas@gmail.com> writes:
> No other programming language that I know of, and no other database
> that I know of, looks at x.y.z and says "ok, well first we have to
> figure out whether the object is named x or x.y or x.y.z, and then
> after that, we'll use whatever is left over as a field selector."

It may indeed be true that nobody but SQL does that, but nonetheless
this is exactly what SQL99 requires AFAICT.  The reason we use this
parenthesis notation is precisely that we didn't want to get into
that sort of tea-leaf-reading about how many identifiers mean what.
The parens put it on the user to tell us what part of the chain
is field selection.

Now do you see why I'd prefer to ditch the SQL92-compatibility
measures?  If we said that the first identifier in a chain must
be a correlation name or parameter name, never anything else,
it'd be substantially saner.

> Yet that's essentially what we've done with period, and I don't think
> we can blame that on the SQL standard

Yes, we can.  Please do not rant further about this until you've
read the <identifier chain> section of a recent SQL spec.

            regards, tom lane



pgsql-hackers by date:

Previous
From: Jimmy Yih
Date:
Subject: Re: New committers: Melanie Plageman, Richard Guo
Next
From: Andres Freund
Date:
Subject: Re: New committers: Melanie Plageman, Richard Guo