Subject: RowDescription for a function does not include table OID

From: Maxwell Dreytser <[email-masked]>
Date: Tue, 18 Jun 2024 03:18:40 +0000

Hello,

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)". Unfortunately RowDescription messages don't contain nearly enough information (no nullability). In pg_type the pg_proc.prorettype of this function shows up as a composite type with a valid typrelid. I am interested in getting this typrelid in the RowDescription field table OID field and the respective attribute number field. This would allow me to figure out all the necessary information by looking up in pg_attribute.

If this is something that might be accepted, I would be willing to work on a patch to implement this change.

Thank you,
Maxwell.

---

From: Tom Lane <[email-masked]>
Date: Mon, 17 Jun 2024 23:51:18 -0400

Maxwell Dreytser <[email-masked]> 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 =
'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 information (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 table OID field and the respective attribute number field. This would allow me to figure out all the necessary information by looking up in pg_attribute.

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

---

From: Maxwell Dreytser <[email-masked]>
Date: Tue, 18 Jun 2024 04:28:34 +0000

>Hmm, I do not think that syntax means what you think it means ;-).

Its an interesting trick that I came across on DBA SE on a question named "How to use RETURNS TABLE with an existing table in PostgreSQL?".

>physical_table'::regtype anyway thanks to some special rules about

The query I am running is "SELECT * FROM my_function()". According to Wireshark I can see that the returned RowDescription shows 0 for Table OID and Column index:

PostgreSQL
    Type: Row description
    Length: 219
    Field count: 7
        Column name: table_id
            Table OID: 0
            Column index: 0
            Type OID: 20
            Column length: 8
            Type modifier: -1
            Format: Binary (1)
<snipped>

>get what you need from the composite type OID?

I would indeed like the relation OID to be returned for the composite type that is returned from the function. Maybe this can be simply considered a bug as it does seem like returning the relation OID that is clearly available would be the expected behaviour.

Regards,
Maxwell.