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 PostgreSQL : PostgreSQL |
"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
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 |
From | Date | Subject | |
---|---|---|---|
Next Message | Jeroen Vermeulen | 2024-12-21 12:54:32 | libpq: make PGresult* "const" in PQcmdStatus()/PQcmdTuples()? |
Previous Message | Tom Lane | 2024-06-21 16:12:43 | Re: RowDescription for a function does not include table OID |