Horton

Re: pg18: Virtual generated columns are not (yet) safe when superuser selects from them

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

View thread
From: Tom Lane <tgl@sss.pgh.pa.us>
To: Matthias van de Meent <boekewurm+postgres@gmail.com>
Cc: Robert Haas <robertmhaas@gmail.com>, Feike Steenbergen <feikesteenbergen@gmail.com>, jian he <jian.universality@gmail.com>, "David G. Johnston" <david.g.johnston@gmail.com>, PostgreSQL mailing lists <pgsql-hackers@postgresql.org>
Date: 2025-05-29T18:30:29Z
Lists: pgsql-hackers

Commits

Same data as JSON: GET /api/v1/messages/:b64id/commits the thread's linked commits as JSON, with link sources. API reference →

  1. Restrict virtual columns to use built-in functions and types

  2. Fix virtual generated column type checking for ALTER TABLE

  3. Expand virtual generated columns in the planner

Matthias van de Meent <boekewurm+postgres@gmail.com> writes:
> On Thu, 29 May 2025 at 15:44, Robert Haas <robertmhaas@gmail.com> wrote:
>> But so far - apart from this feature - we
>> have managed to avoid making it categorically unsafe for the superuser
>> to run "SELECT * FROM table"

> With CREATE RULE [0], a table owner can redefine what happens during
> e.g. SELECT * FROM table.

That's a view, not a table.  The distinction is critical in pg_dump,
and we also have restrict_nonsystem_relation_kind which can be used
to prevent accidental reads from views.  It would definitely be nice
to have a less hacky answer.  But making ordinary tables unsafe to
read absolutely is a quantum jump in insecurity; claiming otherwise
is not helpful.

			regards, tom lane