Re: RowDescription for a function does not include table OID

On Fri, Jun 21, 2024 at 8:04 AM Maxwell Dreytser <
Maxwell(dot)Dreytser(at)assistek(dot)com> wrote:

> On Friday, June 21, 2024 10:48 AM David G. Johnston <
> david(dot)g(dot)johnston(at)gmail(dot)com>wrote:
>
> >Yes, but the bug is yours. The definition you want is: RETURNS SETOF
> physical_table (not tested though)
> >What you did was produce a one-column table whose column type is a
> composite (and whose name is like - what with case-folding of unquoted
> identifiers). Since that table doesn't exist anywhere in the catalogs it
> has no TableOID.
>
> SETOF also does not return correct RowDescription data. Table OID and
> column number are still both 0.
> Both versions have the exact same pg_proc.prorettype. If I join this onto
> pg_type, the pg_type.typrelid = 'physical_table'::regclass.
>
>
Interesting, then I suppose it is semantics. There is no table involved -
you are referencing the type of that name, not the table - so no TableOID.
There is no guarantee the row you are holding came from a table - and I'd
interpret the current behavior as conveying that fact. Though the current
wording: "If the field can be identified as a column of a specific table,
the object ID of the table; otherwise zero."; and the observation that at
least a human "can identify" a related column, leads one to reasonably
infer the system should be able to make such an identification as well.

I would expect you'd be able to find the pg_type.oid value somewhere in the
RowDescription given those specifications, but not the pg_type.typrelid
value. But since the header has no allowance for a row type oid this
information does seem to be missing.

In short, the system doesn't generate the information you need, where you
need it, to tie these pieces together. Modifying existing elements of the
backend protocol is not presently in the cards.

David J.