| From: | Jeff Davis <pgsql(at)j-davis(dot)com> |
|---|---|
| To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, "David G(dot) Johnston" <david(dot)g(dot)johnston(at)gmail(dot)com> |
| Cc: | Robert Haas <robertmhaas(at)gmail(dot)com>, Feike Steenbergen <feikesteenbergen(at)gmail(dot)com>, jian he <jian(dot)universality(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-03 00:23:44 |
| Message-ID: | 156542c6fb54bfadf2e67bcb419749bba6e65149.camel@j-davis.com |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
On Thu, 2025-05-29 at 11:12 -0400, Tom Lane wrote:
> Perhaps a compromise is to invent RunAsUser but only apply it to
> virtual columns for now, leaving the view case as a research
> project. Then we aren't destroying the performance of any
> existing queries.
Could we instead check that the expression is safe at the time the
generated column is created? For the purposes of this thread, "safe"
means "safe for the one running the SELECT".
If the expression only involves functions and operators that are owned
by the superuser (and/or in pg_catalog), or SECURITY DEFINER, then I
think it's safe. It's not released yet, so we can start out more
conservative (as long as it works for most use cases) and then make it
a more precise check in the future.
There are some details to work out. For instance, what happens if a
function starts out as SECURITY DEFINER and then someone changes it
later?
Regards,
Jeff Davis
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Donghang Lin | 2025-06-03 00:40:18 | Re: bt_index_parent_check and concurrently build indexes |
| Previous Message | Masahiko Sawada | 2025-06-03 00:14:35 | Re: Periodic FSM vacuum doesn't happen in one-pass strategy vacuum. |