| From: | Jim Jones <jim(dot)jones(at)uni-muenster(dot)de> |
|---|---|
| To: | Ayoub Kazar <ayoub(dot)kazar(at)data-bene(dot)io>, pgsql-hackers(at)lists(dot)postgresql(dot)org |
| Subject: | Re: Fix exclude generated columns in COPY TO with RLS |
| Date: | 2026-11-05 11:34:26 |
| Message-ID: | 98e35125-71fe-47c5-bba9-2336ea246124@uni-muenster.de |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
Hi Ayoub
On 04/11/2026 13:58, Ayoub Kazar wrote:
>
> The attached patch uses the existing attnums to build targetlist based
> on it, in the case of RLS.
I tested the patch and it solves the reported issue. It also changes how
COPY TO handles columns that the user has no select privileges on,but
I'd argue this is an improvement:
create user u login;
create table t(a int, b int generated always as (a+40) stored, c text);
insert into t (a,c) values (2,'foo');
grant select (a,c) on t to u;
alter table t enable row level security;
create policy p on t using (true);
== master ==
postgres=# set role u;
SET
postgres=> copy t to stdout;
ERROR: permission denied for table t
== patched ==
postgres=# set role u;
SET
postgres=> copy t to stdout;
2 foo
postgres=>
I guess this test could also be added to the regression tests.
BTW, is there another reason to not allow generated columns in COPY TO
other than being consistent with COPY FROM?
Thanks!
Best, Jim
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Jakub Wartak | 2026-11-05 11:45:07 | Re: enhancing pg_basebackup speeds up to ~23Gbps (small fixes + io_uring/Direct I/O) |
| Previous Message | Dilip Kumar | 2026-11-05 11:21:59 | Re: Incorrect CONTEXT reported for errors from parallel apply worker in logical replication |