Re: ExecTypeSetColNames is fundamentally broken - Mailing list pgsql-hackers

From Tom Lane
Subject Re: ExecTypeSetColNames is fundamentally broken
Date
Msg-id 3501514.1638898248@sss.pgh.pa.us
Whole thread Raw
In response to Re: ExecTypeSetColNames is fundamentally broken  (Robert Haas <robertmhaas@gmail.com>)
Responses Re: ExecTypeSetColNames is fundamentally broken  (Robert Haas <robertmhaas@gmail.com>)
List 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 by date:

Previous
From: "Bossart, Nathan"
Date:
Subject: Re: Add sub-transaction overflow status in pg_stat_activity
Next
From: "Bossart, Nathan"
Date:
Subject: Re: Pre-allocating WAL files