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
