| From: | Maxwell Dreytser <Maxwell(dot)Dreytser(at)assistek(dot)com> |
|---|---|
| To: | "David G(dot) Johnston" <david(dot)g(dot)johnston(at)gmail(dot)com> |
| Cc: | "pgsql-general(at)lists(dot)postgresql(dot)org" <pgsql-general(at)lists(dot)postgresql(dot)org> |
| Subject: | Re: RowDescription for a function does not include table OID |
| Date: | 2024-06-21 15:03:58 |
| Message-ID: | LV3PR16MB6001FF31889B0B0DD4EF6476E6C92@LV3PR16MB6001.namprd16.prod.outlook.com |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-general pgsql-interfaces |
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.
Regards,
Maxwell
| From | Date | Subject | |
|---|---|---|---|
| Next Message | David G. Johnston | 2024-06-21 15:28:56 | Re: RowDescription for a function does not include table OID |
| Previous Message | David G. Johnston | 2024-06-21 14:48:16 | Re: RowDescription for a function does not include table OID |
| From | Date | Subject | |
|---|---|---|---|
| Next Message | David G. Johnston | 2024-06-21 15:28:56 | Re: RowDescription for a function does not include table OID |
| Previous Message | David G. Johnston | 2024-06-21 14:48:16 | Re: RowDescription for a function does not include table OID |