Robert Haas <robertmhaas@gmail.com> writes:
> On Fri, Apr 26, 2024 at 12:15 PM Tom Lane <tgl@sss.pgh.pa.us> wrote:
>> 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.
> 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.
I think you're moving the goal posts too far. It's on the user to
spell the initially-written query unambiguously: if you chose a
function parameter name that matches a table correlation name in the
query, that's your fault and you'd better rename one of those things.
What concerns me is the hazard that the query is okay, and we store
it, and then subsequent object creations or renamings create a
situation where an identifier chain is ambiguous per the SQL99 rules.
ruleutils has to be able to deparse the stored query in a way that is
valid regardless of that. Giving first priority to correlation and
parameter names makes this possible because external operations, even
including renaming tables or columns used in the query, won't affect
either.
regards, tom lane
PS: ruleutils does sometimes choose new correlation names, and it
suddenly occurs to me that it's probably not being careful to avoid
duplicating function parameter names. But that's independent of this
discussion.