public inbox for [email protected]help / color / mirror / Atom feed
RowDescription for a function does not include table OID 3+ messages / 2 participants [nested] [flat]
* RowDescription for a function does not include table OID @ 2024-06-18 03:18 Maxwell Dreytser <[email protected]> 2024-06-18 03:51 ` Re: RowDescription for a function does not include table OID Tom Lane <[email protected]> 0 siblings, 1 reply; 3+ messages in thread From: Maxwell Dreytser @ 2024-06-18 03:18 UTC (permalink / raw) To: [email protected] <[email protected]> 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. ^ permalink raw reply [nested|flat] 3+ messages in thread
* Re: RowDescription for a function does not include table OID 2024-06-18 03:18 RowDescription for a function does not include table OID Maxwell Dreytser <[email protected]> @ 2024-06-18 03:51 ` Tom Lane <[email protected]> 2024-06-18 04:28 ` Re: RowDescription for a function does not include table OID Maxwell Dreytser <[email protected]> 0 siblings, 1 reply; 3+ messages in thread From: Tom Lane @ 2024-06-18 03:51 UTC (permalink / raw) To: Maxwell Dreytser <[email protected]>; +Cc: [email protected] <[email protected]> Maxwell Dreytser <[email protected]> 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 ^ permalink raw reply [nested|flat] 3+ messages in thread
* Re: RowDescription for a function does not include table OID 2024-06-18 03:18 RowDescription for a function does not include table OID Maxwell Dreytser <[email protected]> 2024-06-18 03:51 ` Re: RowDescription for a function does not include table OID Tom Lane <[email protected]> @ 2024-06-18 04:28 ` Maxwell Dreytser <[email protected]> 0 siblings, 0 replies; 3+ messages in thread From: Maxwell Dreytser @ 2024-06-18 04:28 UTC (permalink / raw) To: Tom Lane <[email protected]>; +Cc: [email protected] <[email protected]> From: Tom Lane <[email protected]>: >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?". >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 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> >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 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. ^ permalink raw reply [nested|flat] 3+ messages in thread
end of thread, other threads:[~2024-06-18 04:28 UTC | newest] Thread overview: 3+ messages (download: mbox mbox.gz follow: Atom feed) -- links below jump to the message on this page -- 2024-06-18 03:18 RowDescription for a function does not include table OID Maxwell Dreytser <[email protected]> 2024-06-18 03:51 ` Tom Lane <[email protected]> 2024-06-18 04:28 ` Maxwell Dreytser <[email protected]>
This inbox is served by agora; see mirroring instructions for how to clone and mirror all data and code used for this inbox