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

From: Robert Haas <robertmhaas(at)gmail(dot)com>
To: Peter Eisentraut <peter(at)eisentraut(dot)org>
Cc: Feike Steenbergen <feikesteenbergen(at)gmail(dot)com>, PostgreSQL mailing lists <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: pg18: Virtual generated columns are not (yet) safe when superuser selects from them
Date: 2025-06-05 14:38:58
Message-ID: CA+TgmoZBbfx4Sjud-ZSGRrMSk_9iLPncdj8+rycXPre-eApQuQ@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Thu, Jun 5, 2025 at 6:49 AM Peter Eisentraut <peter(at)eisentraut(dot)org> wrote:
> I propose to address this by not allowing the use of user-defined
> functions in generation expressions for now. The attached patch
> implements this. This assumes that all built-in functions are
> trustworthy, for this purpose, which seems likely true and likely desirable.
>
> I think the feature is still useful like that, and this approach
> provides a path to add new functionality in the future that grows this
> set of allowed functions, for example by allowing some configurable set
> of "trusted" functions or whatever.

I don't think this is sufficient to fix the problem. We have built-in
functions that are unsafe. These include LO functions like loread(),
lowrite(), lo_unlink(); functions that change session state like
set_config() and setseed(); functions that allow arbitrary query
execution like query_to_xml(); slot-manipulation functions like
pg_drop_replication_slot(); and maybe other things.

Even if it worked, I think it's an unappealing solution -- we've
worked really hard at extensibility and making decisions based on
object properties rather than what's built-in and what's provided by a
user or an extension. But I also don't think it works.

--
Robert Haas
EDB: http://www.enterprisedb.com

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2025-06-05 15:10:04 Re: Wrong security context for deferred triggers?
Previous Message David Rowley 2025-06-05 14:06:14 Re: Question Regarding Merge Append and Parallel Execution of Index Scans on Partitioned Table