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

I wrote:
> I could get behind offering an alternative notation, eg "a.b->c does
> the same thing as (a.b).c", if we could find a reasonable notation
> that doesn't infringe on user operator namespace. I think that might
> be hard to do though, and I don't think the existing notation is so
> awful than we should break existing operators to have an alternative.
> The business with deprecating => operators a few years ago had the
> excuse that "the standard says so", but we don't have that
> justification here.

A different approach we could take is to implement the SQL99 rules
for <identifier chain>, or at least move closer to that. Our
existing rules for resolving qualified column references are more
or less SQL92. I think the reasons we didn't do that when we first
implemented SQL99 are

(1) The SQL99 rules are fundamentally ambiguous, which they wave
away by saying that it's user error if there's more than one way
to interpret the reference. This approach is decidedly not nice,
notably because it means that unrelated-looking changes in your
schema can break your query. Having to check multiple
interpretations slows parsing, too.

(2) Switching from SQL92 to SQL99 rules would break some queries
anyway. (At least, that's my recollection, though looking at
the specs right now I don't see any case where SQL99 doesn't
take a SQL92 alternative, so long as you don't run into (1).)

Still, maybe it's time to think about changing? We could use
the "the standard says so" excuse with anybody who complains.

In the long run I wish we could ditch the SQL92 rules altogether
and say that the head identifier of a qualified column reference
must be a table's correlation name, not a schema or catalog name.
There's zero good reason for the latter two cases, other than
compatibility with thirty-year-old design mistakes. I kind of
doubt we could make that fly though.

regards, tom lane