Thread: RowDescription for a function does not include table OID
Hello, I am working on a meta-programming use-case where I need to scrape some detailed information about the results of a functioncall that "RETURNS TABLE (LIKE physical_table)". Unfortunately RowDescription messages don't contain nearly enoughinformation (no nullability). In pg_type the pg_proc.prorettype of this function shows up as a composite type witha valid typrelid. I am interested in getting this typrelid in the RowDescription field table OID field and the respectiveattribute 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.
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 =
'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.prorettypeof 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
numberfield. 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: Tom Lane <tgl@sss.pgh.pa.us>:
>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
tablein PostgreSQL?".
>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?
The query I am running is "SELECT * FROM my_function()". According to Wireshark I can see that the returned
RowDescriptionshows 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>
>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?
I would indeed like the relation OID to be returned for the composite type that is returned from the function. Maybe
thiscan be simply considered a bug as it does seem like returning the relation OID that is clearly available would be
theexpected behaviour.
Regards,
Maxwell.
From: Tom Lane <tgl@sss.pgh.pa.us>: >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 tablein PostgreSQL?". >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? The query I am running is "SELECT * FROM my_function()". According to Wireshark I can see that the returned RowDescriptionshows 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> >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? I would 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 wouldbe the expected behavior. Regards, Maxwell.