Re: TupleDescAttr bounds checks - Mailing list pgsql-hackers

From Tom Lane
Subject Re: TupleDescAttr bounds checks
Date
Msg-id 504241.1775360727@sss.pgh.pa.us
Whole thread Raw
In response to Re: TupleDescAttr bounds checks  (Peter Eisentraut <peter@eisentraut.org>)
List pgsql-hackers
Peter Eisentraut <peter@eisentraut.org> writes:
> On 04.04.26 17:38, Tom Lane wrote:
>> 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.

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

Ah, indeed.  Jian's patch in that thread seems rough but potentially
workable to me, but seemingly the thread tailed off for lack of
interest.  I don't want to revive it now as part of a bug fix.

Disallowing tableoid for now, and then re-allowing it if someone
picks up that patch down the road, seems like a good solution.
For one thing, since that patch changes the semantics of tableoid
in COPY WHERE, I think it'd be a good idea to have a release or
two in between where we throw error.  That'd be helpful to flush
out any field usages that might be affected.

            regards, tom lane



pgsql-hackers by date:

Previous
From: Thomas Munro
Date:
Subject: Trying out libarchive for reading user-generated WAL tarballs
Next
From: Andres Freund
Date:
Subject: Re: Changing the state of data checksums in a running cluster