Re: ExecTypeSetColNames is fundamentally broken
Robert Haas <robertmhaas@gmail.com>
From: Robert Haas <robertmhaas@gmail.com>
To: Tom Lane <tgl@sss.pgh.pa.us>
Cc: PostgreSQL Hackers <pgsql-hackers@lists.postgresql.org>
Date: 2021-12-07T17:58:48Z
Lists: pgsql-hackers
On Tue, Dec 7, 2021 at 12:30 PM Tom Lane <tgl@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.
> Another way to phrase the issue is that the column names seen
> by f() are currently different from those seen by row_to_json():
>
> regression=# select row_to_json(t) from t as t(x,y);
> row_to_json
> -----------------
> {"x":11,"y":12}
> (1 row)
>
> and that seems hard to justify.
Yeah, I agree. The problem I have here is that, with your proposed
fix, it still won't be very consistent. True, row_to_json() and f()
will both see the unaliased column names ... but a straight select *
from t as t(x,y) will show the aliased names. That's unarguably better
than corrupting your data, but it seems "astonishing" in the POLA
sense.
--
Robert Haas
EDB: http://www.enterprisedb.com
Commits
-
Don't bother to attach column name lists to RowExprs of named types.
- d7b5c071dd6a 15.0 landed
-
Revert applying column aliases to the output of whole-row Vars.
- ec62cb0aac5b 15.0 landed
- 5e144cc89b46 13.7 landed
- 205214c8b8cc 10.21 landed
- 1f5ef5ae0806 12.11 landed
- 1d072bd2030a 14.3 landed
- 13b54d1e0dde 11.16 landed