From: Tom Lane <tgl@sss.pgh.pa.us>
To: Maxwell Dreytser <Maxwell.Dreytser@assistek.com>
cc: "pgsql-interfaces@lists.postgresql.org" <pgsql-interfaces@lists.postgresql.org>
Subject: Re: RowDescription for a function does not include table OID
In-reply-to: <LV3PR16MB6001AF4D05893E9FF4B3C746E6CE2@LV3PR16MB6001.namprd16.prod.outlook.com>
References: <LV3PR16MB6001AF4D05893E9FF4B3C746E6CE2@LV3PR16MB6001.namprd16.prod.outlook.com>
Comments: In-reply-to Maxwell Dreytser <Maxwell.Dreytser@assistek.com>
	message dated "Tue, 18 Jun 2024 03:18:40 -0000"
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-ID: <3528231.1718682678.1@sss.pgh.pa.us>
Content-Transfer-Encoding: quoted-printable
Date: Mon, 17 Jun 2024 23:51:18 -0400
Message-ID: <3528232.1718682678@sss.pgh.pa.us>
Archived-At: <https://www.postgresql.org/message-id/3528232.1718682678%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 call that
> "RETURNS TABLE (LIKE physical_table)".

Hmm, I do not think that syntax means what you think it means ;-).
However, it seems to end up with prorettype =3D
'physical_table'::regtype anyway thanks to some special rules about
single-column output tables, so as far as I can see you should get
the table's composite type OID as the column type OID in the result
descriptor for "SELECT my_function(...)".  Or is that not the case
you're concerned about?

> Unfortunately RowDescription messages don't contain nearly enough inform=
ation (no nullability). In pg_type the pg_proc.prorettype of this function=
 shows up as a composite type with a valid typrelid.

Right ...

> I am interested in getting this typrelid in the RowDescription field tab=
le OID field and the respective attribute number field. This would allow m=
e to figure out all the necessary information by looking up in pg_attribut=
e.

I'm confused about exactly what you're asking for, but (a) returning a
type OID where a relation OID is expected is absolutely not OK ---
there is no guarantee that those OID sets are distinct; (b) regardless
of that, you seem to be asking for a silent semantic change in the
wire protocol, which is going to be a very hard sell because it will
probably break more applications than it makes happy.  Why can't you
get what you need from the composite type OID?

			regards, tom lane