Re: TupleDescAttr bounds checks - Mailing list pgsql-hackers

From Peter Eisentraut
Subject Re: TupleDescAttr bounds checks
Date
Msg-id 55199b03-dd62-46d3-be0a-e39217b27333@eisentraut.org
Whole thread Raw
In response to Re: TupleDescAttr bounds checks  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: TupleDescAttr bounds checks
List pgsql-hackers
On 04.04.26 17:38, Tom Lane wrote:
> I wrote:
>> But I bet this loop should throw an error for system columns, too,
>> since we surely won't have computed those either.
> 
> After poking at that: testing tableoid does sort of work, in that it
> reads as the OID of the target table named in COPY.  But I think any
> rational use for a test on tableoid here would be in connection with
> a partitioned target table, and the user would wish it to read as the
> OID of the destination partition.  So I think we should disallow
> tableoid along with the other system columns, pending somebody having
> the ambition to make that work.
> 
> So I propose the attached for HEAD.  (I couldn't resist the temptation
> to clean up adjacent comments.)  In the back branches it might be
> better to just ignore system columns here, on the tiny chance that
> somebody thinks they do something useful.

I think this is the same issue that was discussed here:

https://www.postgresql.org/message-id/flat/30c39ee8-bb11-4b8f-9697-45f7e018a8d3%40eisentraut.org

There was no conclusion there, but I agree with the proposal to prohibit 
this use.




pgsql-hackers by date:

Previous
From: Andrei Lepikhov
Date:
Subject: Re: pg_plan_advice
Next
From: Peter Eisentraut
Date:
Subject: Re: PG 19 release notes and authors