Robert Haas <robertmh...@gmail.com> writes:
> On Tue, Dec 7, 2021 at 12:30 PM Tom Lane <t...@sss.pgh.pa.us> wrote:
>> If we consider that the alias renames the columns "for all purposes",
>> how is it okay for f() to select the "a" column?
> I'd say it isn't.
In a green field I'd probably agree with you, but IMO that will
break far too much existing SQL code.
It'd cause problems for us too, not only end-users. As an example,
ruleutils.c would have to avoid attaching new column aliases to
tables that are referenced as whole-row Vars. I'm not very sure
that that's even possible without creating insurmountable ambiguity
issues. There are also fun issues around what happens to a stored
query after a table column rename. Right now the query acts as
though it uses the old name as a column alias, and that introduces
no semantic problem; but that behavior would no longer be
acceptable.
So the alternatives I see are to revert what bf7ca1587 tried to do
here, or to try to make it work that way across-the-board, which
implies (a) a very much larger amount of work, and (b) breaking
important behaviors that are decades older than that commit.
It's not even entirely clear that we could get to complete
consistency if we went down that path.
regards, tom lane
