Horton

Re: TupleDescAttr bounds checks

Tom Lane <tgl@sss.pgh.pa.us>

View thread View on postgr.es
From: Tom Lane <tgl@sss.pgh.pa.us>
To: Alexander Lakhin <exclusion@gmail.com>
Cc: Robert Haas <robertmhaas@gmail.com>, PostgreSQL Hackers <pgsql-hackers@lists.postgresql.org>
Date: 2026-04-04T15:38:24Z
Lists: pgsql-hackers

Attachments

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.

			regards, tom lane

Commits

  1. Avoid unsafe access to negative index in a TupleDesc.

  2. Disallow system columns in COPY FROM WHERE conditions.

  3. Add a test for creating an index on a whole-row expression.

  4. Bounds-check access to TupleDescAttr with an Assert.

  5. Prevent spurious "indexes on virtual generated columns are not supported".