| From: | "David G(dot) Johnston" <david(dot)g(dot)johnston(at)gmail(dot)com> |
|---|---|
| To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
| Cc: | Maxwell Dreytser <Maxwell(dot)Dreytser(at)assistek(dot)com>, "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:57:49 |
| Message-ID: | CAKFQuwZ+_Hmn2oq=DmKyi=h2RJdONLtqH_j_eUdH_oYML3idhA@mail.gmail.com |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-general pgsql-interfaces |
On Fri, Jun 21, 2024 at 8:51 AM Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
>
> The PG wire protocol specification [1] defines these fields thus:
>
> If the field can be identified as a column of a specific
> table, the object ID of the table; otherwise zero.
>
> If the field can be identified as a column of a specific
> table, the attribute number of the column; otherwise zero.
>
> My reading of that is that we should populate these fields only for
> the case of direct selection from a table.
>
s/can be identified as/is/g ?
Experience shows people are inferring a lot from "can be identified" so we
should remove it. "is" maybe over-simplifies a bit but in the correct
direction.
David J.
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Tom Lane | 2024-06-21 16:12:43 | Re: RowDescription for a function does not include table OID |
| Previous Message | David G. Johnston | 2024-06-21 15:52:00 | Re: RowDescription for a function does not include table OID |
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Tom Lane | 2024-06-21 16:12:43 | Re: RowDescription for a function does not include table OID |
| Previous Message | David G. Johnston | 2024-06-21 15:52:00 | Re: RowDescription for a function does not include table OID |