Re: RowDescription for a function does not include table OID

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: "David G(dot) Johnston" <david(dot)g(dot)johnston(at)gmail(dot)com>
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 16:17:46
Message-ID: 600217.1718986666@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-general pgsql-interfaces

"David G. Johnston" <david(dot)g(dot)johnston(at)gmail(dot)com> writes:
> 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.

> 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.

I dunno, that seems to me to be just as open to argument if not
more so. Perhaps some phrasing like "can be directly identified"?

The real point IMV is that it's based purely on parse analysis,
without looking into the behavior of views or functions (which
could change between parsing and execution, anyway).

regards, tom lane

In response to

Browse pgsql-general by date

  From Date Subject
Next Message Tom Lane 2024-06-21 16:46:22 Re: Replication using mTLS issue
Previous Message Tom Lane 2024-06-21 16:12:43 Re: RowDescription for a function does not include table OID

Browse pgsql-interfaces by date

  From Date Subject
Previous Message Tom Lane 2024-06-21 16:12:43 Re: RowDescription for a function does not include table OID