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: Isaac Morland <isaac.morland@gmail.com>
Cc: jian he <jian.universality@gmail.com>, Jeff Davis <pgsql@j-davis.com>, "David G. Johnston" <david.g.johnston@gmail.com>, Robert Haas <robertmhaas@gmail.com>, Feike Steenbergen <feikesteenbergen@gmail.com>, PostgreSQL mailing lists <pgsql-hackers@postgresql.org>
Date: 2025-06-03T03:30:08Z
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

Isaac Morland <isaac.morland@gmail.com> writes:
> On Mon, 2 Jun 2025 at 22:52, jian he <jian.universality@gmail.com> wrote:
> Do we consider INSERT associated with user defined function a security
>> bug?

> A very old issue for INSERT/UPDATE/DELETE, but until this patch not an
> issue for SELECT from a table (although if I understand correctly earlier
> discussion SELECT from a view can already be a problem).

Precisely.

> That being said I would like to see it corrected everywhere.

Yeah, one approach we could take here is to try to move the goalposts
for this whole topic, understanding that that will mean incompatible
changes as well as some performance loss.  I'm not sure how many users
would be happy to take that tradeoff, but some would.  Maybe two
different operating modes would make it an easier sell?

> My fix would
> be for check constraints, triggers, and view definitions to run as the
> owner of the object in question (constraint, trigger, or view or
> materialized view), essentially using the same facility as used to run
> security definer functions. Then, as an optimization only, skip actually
> doing the security definer stuff (which I understand to be slow) when it
> can be proven by the planner to be safe to do so (i.e., no difference in
> result).

I am interested to know how you think the planner could prove that.

			regards, tom lane