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

Robert Haas <robertmhaas(at)gmail(dot)com> writes:
> On Thu, Apr 25, 2024 at 5:51 PM Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
>> A different approach we could take is to implement the SQL99 rules
>> for <identifier chain>, or at least move closer to that.

> I'm not familiar with these rules. Do they allow stuff like a.b.c.d.e,
> or better yet, a.b(args).c(args).d(args).e(args)?

The former.

<identifier chain> ::=
<identifier> [ { <period> <identifier> }... ]

The hard part is to figure out what the first identifier is:
column name? table correlation name (AS name)? schema name or
catalog name of a qualified table name? function parameter name?
After that, as long as what you have is of composite type,
you can drill down into it.

If I'm reading SQL99 correctly, they deny allowing the first
identifier to be a column name when there's more than one identifier,
so that you must table-qualify a composite column before you can
select a field from it. But they allow all the other possibilities
and claim it's user error if more than one could apply, which seems
like an awful design to me. At minimum I'd want to say that the
correlation name should be the first choice and wins if there's
a match, regardless of anything else, because otherwise there is
no safe way for ruleutils to deparse such a construct. And
probably function parameter name should be second choice and
similarly win over other choices, for the same reason. The other
options are SQL92 compatibility holdovers and should only be
considered if we can't find a matching correlation or parameter name.

The net result of doing it like this, I think, is that we'd accept
some cases where SQL99 would prefer to raise an ambiguity error.
But we'd still be much closer to the modern standard than we are
today.

regards, tom lane