Re: Virtual generated columns
От | jian he |
---|---|
Тема | Re: Virtual generated columns |
Дата | |
Msg-id | CACJufxHtarAYA7LZUKbc1NnJ7k-t3+kzicD0ZtHMvJBxvFONpQ@mail.gmail.com обсуждение исходный текст |
Ответ на | Virtual generated columns (Peter Eisentraut <peter@eisentraut.org>) |
Список | pgsql-hackers |
On Thu, Jan 9, 2025 at 12:14 AM Peter Eisentraut <peter@eisentraut.org> wrote: > > Here is a new patch version where I have gathered various pieces of > feedback and improvement suggestions that are scattered over this > thread. I hope I got them all. I will respond to the respective > messages directly to give my response to each item. > > One thing I could use some review on is the access control handling and > security in general. You can create virtual generated columns that have > their own access privileges but which can read columns that the user > does not have access to. Kind of like a view. This all appears to work > correctly, but maybe someone wants to poke a hole into it. > > Here is an example: > > create user foo; > create user bar; > grant create on schema public to foo; > \c - foo > create table t1 (id int, ccnum text, ccredacted text generated always as > (repeat('*', 12) || substr(ccnum, 13, 4)) virtual); > grant select (id, ccredacted) on table t1 to bar; > insert into t1 values (1, '1234567890123456'); > \c - bar > select * from t1; -- permission denied > select id, ccredacted from t1; -- ok I think this is expected. however once the user can access the pg_catalog, then he can use pg_get_expr figure out the generation expression. so here "bar" can figure out the column value of ccnum, i think.
В списке pgsql-hackers по дате отправления: