Re: Virtual generated columns
Dean Rasheed <dean.a.rasheed@gmail.com>
Commits
GET /api/v1/messages/:b64id/commits
the thread's linked commits as JSON, with link sources.
API reference →
-
Expand virtual generated columns for ALTER COLUMN TYPE
- 5069fef1cfae 18.0 landed
-
Eliminate code duplication in replace_rte_variables callbacks
- 363a6e8c6fcf 18.0 landed
-
Expand virtual generated columns in the planner
- 1e4351af329f 18.0 landed
-
Virtual generated columns
- 83ea6c54025b 18.0 landed
-
Additional tests for stored generated columns
- 41084409f635 18.0 landed
-
Improve generated_stored test
- 44b61efb7928 18.0 landed
- 86749ea3b766 18.0 landed
-
Fix handling of CREATE DOMAIN with GENERATED constraint syntax
- 84a67725cd11 18.0 landed
-
Add pg_constraint rows for not-null constraints
- 14e87ffa5c54 18.0 cited
-
Put generated_stored test objects in a schema
- 894be11adfa6 18.0 landed
-
Rename regress test generated to generated_stored
- b9ed4969250d 18.0 landed
-
Small code simplification
- 7ff9afbbd1df 18.0 landed
-
Remove useless code
- e26d313bad92 18.0 landed
-
Remove useless initializations
- da2aeba8f533 18.0 landed
-
doc: Clarify that pg_attrdef also stores generation expressions
- da486d360103 18.0 landed
-
Clean out column-level pg_init_privs entries when dropping tables.
- 76618097a6c0 17.0 cited
-
Re-implement the ereport() macro using __VA_ARGS__.
- e3a87b4991cc 13.0 cited
On Wed, 8 Jan 2025 at 16:14, Peter Eisentraut <peter@eisentraut.org> wrote:
>
> 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.
That looks correct to me. Permissions are checked on the columns
mentioned in the query, not whatever columns the virtual generated
column's expression refers to. If it were a view, there'd be
additional checks that the view owner had the required privileges on
the referenced columns, but for virtual columns in a table, there is
no separate view owner, so no additional checks are necessary.
> 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
Makes sense.
Regards,
Dean