From: Tom Lane <tgl@sss.pgh.pa.us>
To: Maxwell Dreytser <Maxwell.Dreytser@assistek.com>
cc: "pgsql-general@lists.postgresql.org" <pgsql-general@lists.postgresql.org>
Subject: Re: RowDescription for a function does not include table OID
In-reply-to: <LV3PR16MB60014D610A726368182ACC7EE6C92@LV3PR16MB6001.namprd16.prod.outlook.com>
References: <LV3PR16MB6001AF4D05893E9FF4B3C746E6CE2@LV3PR16MB6001.namprd16.prod.outlook.com> <3528232.1718682678@sss.pgh.pa.us> <LV3PR16MB6001CD31C5982777BA9BA25EE6CE2@LV3PR16MB6001.namprd16.prod.outlook.com> <LV3PR16MB6001216CE02B2D908F9D87ECE6C82@LV3PR16MB6001.namprd16.prod.outlook.com> <LV3PR16MB60014D610A726368182ACC7EE6C92@LV3PR16MB6001.namprd16.prod.outlook.com>
Comments: In-reply-to Maxwell Dreytser <Maxwell.Dreytser@assistek.com>
	message dated "Fri, 21 Jun 2024 14:41:55 -0000"
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-ID: <597260.1718985078.1@sss.pgh.pa.us>
Content-Transfer-Encoding: quoted-printable
Date: Fri, 21 Jun 2024 11:51:18 -0400
Message-ID: <597261.1718985078@sss.pgh.pa.us>
Archived-At: <https://www.postgresql.org/message-id/597261.1718985078%40sss.pgh.pa.us>
Precedence: bulk

Maxwell Dreytser <Maxwell.Dreytser@assistek.com> writes:
> I am working on a meta-programming use-case where I need to scrape some =
detailed information about the results of a function that "RETURNS TABLE (=
LIKE physical_table)", which ends up with prorettype =3D 'physical_table':=
:regtype.
> The problem is that for the query "SELECT * FROM my_function()" the RowD=
escription that is sent back shows 0 for Table OID and Column Index.

Yes, that's expected.  You're selecting from a function, not a table.

> I would expect that the Table OID contains the relation OID of this
> table, as it would do for a typical statement like "SELECT * FROM
> my_table".

The PG wire protocol specification [1] defines these fields thus:

	If the field can be identified as a column of a specific
	table, the object ID of the table; otherwise zero.

	If the field can be identified as a column of a specific
	table, the attribute number of the column; otherwise zero.

My reading of that is that we should populate these fields only for
the case of direct selection from a table.  If you go further than
that, then first off you have a ton of definitional issues (should it
"look through" views, for example?), and second you probably break
applications that are expecting the existing, longstanding definition.

			regards, tom lane

[1] https://www.postgresql.org/docs/current/protocol-message-formats.html