From: | Robert Haas <robertmhaas(at)gmail(dot)com> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org> |
Subject: | Re: ExecTypeSetColNames is fundamentally broken |
Date: | 2021-12-07 17:58:48 |
Message-ID: | CA+TgmoYX8ZsL5BoYeJD+QK9iCQLBdq1mbQ_ZiwZGKBwzgFZYWA@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Tue, Dec 7, 2021 at 12:30 PM Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)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
From | Date | Subject | |
---|---|---|---|
Next Message | Alexander Lakhin | 2021-12-07 17:59:59 | Re: MSVC SSL test failure |
Previous Message | Bossart, Nathan | 2021-12-07 17:49:57 | Re: Alter all tables in schema owner fix |