Re: ExecTypeSetColNames is fundamentally broken

Поиск
Список
Период
Сортировка
От Tom Lane
Тема Re: ExecTypeSetColNames is fundamentally broken
Дата
Msg-id 3501514.1638898248@sss.pgh.pa.us
обсуждение исходный текст
Ответ на Re: ExecTypeSetColNames is fundamentally broken  (Robert Haas <robertmhaas@gmail.com>)
Ответы Re: ExecTypeSetColNames is fundamentally broken  (Robert Haas <robertmhaas@gmail.com>)
Список pgsql-hackers
Robert Haas <robertmhaas@gmail.com> writes:
> On Mon, Dec 6, 2021 at 4:05 PM Tom Lane <tgl@sss.pgh.pa.us> wrote:
>> select f(t) from t(x,y);
>> 
>> If we adopt the "rename for all purposes" interpretation, then
>> the second SELECT must fail, because what f() is being passed is
>> no longer of type t.

> For me, the second SELECT does fail:

> rhaas=# select f(t) from t(x,y);
> ERROR:  column "x" does not exist

Ah, sorry, I fat-fingered the alias syntax.  Here's a tested example:

regression=# create table t (a int, b int);
CREATE TABLE
regression=# insert into t values(11,12);
INSERT 0 1
regression=# create function f(t) returns int as 'select $1.a' language sql;
CREATE FUNCTION
regression=# select f(t) from t as t(x,y);
 f  
----
 11
(1 row)

If we consider that the alias renames the columns "for all purposes",
how is it okay for f() to select the "a" column?

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.

            regards, tom lane



В списке pgsql-hackers по дате отправления:

Предыдущее
От: "Bossart, Nathan"
Дата:
Сообщение: Re: Add sub-transaction overflow status in pg_stat_activity
Следующее
От: "Bossart, Nathan"
Дата:
Сообщение: Re: Pre-allocating WAL files