Re: Why don't we support external input/output functions for the composite types

Robert Haas <robertmhaas(at)gmail(dot)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