On Fri, Apr 26, 2024 at 12:15 PM Tom Lane <tgl@sss.pgh.pa.us> wrote:
> > 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> }... ]
OK, nice.
> 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.
Right, makes sense.
> 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.
I definitely agree that there must always be some way to make it
unambiguous, not just because of deparsing but also because users are
going to want a way to force their preferred interpretation. I've been
a PostgreSQL developer now for considerably longer than I was an end
user, but I definitely would not have liked "ERROR: you can't get
there from here".
I'm less certain how that should be spelled. The rules you propose
make sense to me up to a point, but what happens if the same
unqualified name is both a table alias and a function parameter name?
I think I need a way of forcing the function-parameter interpretation.
You could make function_name.parameter_name resolve to that, but then
what happens if function_name is also a table alias in the containing
query? It's really hard to think of a set of rules here that don't
leave any room for unfixable problems. Maybe the answer is that we
should support some completely different notion for unambiguously
referencing parameters, like ${parameter_name}. I don't know. I think
that what you're proposing here could be a nice improvement but it
definitely seems tricky to get it completely right.
--
Robert Haas
EDB: http://www.enterprisedb.com
