Re: Add SPLIT PARTITION/MERGE PARTITIONS commands
Alexander Lakhin <exclusion@gmail.com>
Commits
GET /api/v1/messages/:b64id/commits
the thread's linked commits as JSON, with link sources.
API reference →
-
Adjust errcode in checkPartition()
- d51a5d8e5692 19 (unreleased) landed
-
Fix usage of palloc() in MERGE/SPLIT PARTITION(s) code
- c5ae07a90a0f 19 (unreleased) landed
-
Implement ALTER TABLE ... SPLIT PARTITION ... command
- 4b3d173629f4 19 (unreleased) landed
- 87c21bb9412c 17.0 landed
-
Implement ALTER TABLE ... MERGE PARTITIONS ... command
- f2e4cc427951 19 (unreleased) landed
- 1adf16b8fba4 17.0 landed
-
Calculate agglevelsup correctly when Aggref contains a CTE.
- b0cc0a71e0a0 19 (unreleased) cited
-
Use PqMsg_* macros in applyparallelworker.c.
- 989b2e4d5c95 19 (unreleased) cited
-
Restrict psql meta-commands in plain-text dumps.
- 71ea0d679543 19 (unreleased) cited
-
Ensure we have a snapshot when updating various system catalogs.
- 706054b11b95 18.0 cited
-
Use specific collation where needed in new test
- 17bcf4f54504 18.0 cited
-
Expand virtual generated columns in the planner
- 1e4351af329f 18.0 cited
-
Virtual generated columns
- 83ea6c54025b 18.0 cited
-
Define PG_LOGICAL_DIR for path pg_logical/ in data folder
- c39afc38cfec 18.0 cited
-
Revert support for ALTER TABLE ... MERGE/SPLIT PARTITION(S) commands
- 84f594da3588 17.0 landed
- 3890d90c1508 18.0 landed
-
Avoid repeated table name lookups in createPartitionTable()
- f636ab41aba2 17.0 landed
- 04158e7fa37c 18.0 landed
-
Provide deterministic order for catalog queries in partition_split.sql
- d53a4286d772 17.0 landed
-
Don't copy extended statistics during MERGE/SPLIT partition operations
- fbd4321fd5b4 17.0 landed
-
Fix the name collision detection in MERGE/SPLIT partition operations
- 3a82c689fd1b 17.0 landed
-
Fix regression tests conflict in 3ca43dbbb6
- 2a679ae94e46 17.0 landed
-
Add permission check for MERGE/SPLIT partition operations
- 3ca43dbbb67f 17.0 landed
-
Fix one more portability shortcoming in new test_pg_dump test.
- d12b4ba1bd3e 17.0 cited
-
Inherit parent's AM for partition MERGE/SPLIT operations
- 259c96fa8f78 17.0 landed
-
Add tab completion for partition MERGE/SPLIT operations
- 60ae37a8bc02 17.0 landed
-
Rename tables in tests of partition MERGE/SPLIT operations
- f4fc7cb54b6a 17.0 landed
-
Make new partitions with parent's persistence during MERGE/SPLIT
- fcf80c5d5f0f 17.0 landed
-
Document the way partition MERGE/SPLIT operations create new partitions
- 842c9b27057e 17.0 landed
-
Change the way ATExecMergePartitions() handles the name collision
- 885742b9f88b 17.0 landed
-
Grammar fixes for split/merge partitions code
- 9dfcac8e15ac 17.0 landed
-
Checks for ALTER TABLE ... SPLIT/MERGE PARTITIONS ... commands
- c99ef1811a06 17.0 landed
-
Fix some grammer errors from error messages and codes comments
- df64c81ca9cb 17.0 landed
-
Support TZ and OF format codes in to_timestamp().
- 8ba6fdf905d0 17.0 cited
-
Support identity columns in partitioned tables
- 699586315704 17.0 cited
-
Fix indentation in twophase.c
- 4e465aac36ce 17.0 cited
-
Fix corner-case planner failure for MERGE.
- 326a33a289c7 16.0 cited
-
Doc: fix documentation example for bytea hex output format.
- 4f46f870fa56 16.0 cited
-
Avoid repeated name lookups during table and index DDL.
- 5f173040e324 9.4.0 cited
Hello, 28.04.2024 03:59, Alexander Korotkov wrote: > The revised patchset is attached. I'm going to push it if there are > no objections. I have one additional question regarding security, if you don't mind: What permissions should a user have to perform split/merge? When we deal with mixed ownership, say, bob is an owner of a partitioned table, but not an owner of a partition, should we allow him to perform merge with that partition? Consider the following script: CREATE ROLE alice; GRANT CREATE ON SCHEMA public TO alice; SET SESSION AUTHORIZATION alice; CREATE TABLE t (i int PRIMARY KEY, t text, u text) PARTITION BY RANGE (i); CREATE TABLE tp_00 PARTITION OF t FOR VALUES FROM (0) TO (10); CREATE TABLE tp_10 PARTITION OF t FOR VALUES FROM (10) TO (20); CREATE POLICY p1 ON tp_00 USING (u = current_user); ALTER TABLE tp_00 ENABLE ROW LEVEL SECURITY; INSERT INTO t(i, t, u) VALUES (0, 'info for bob', 'bob'); INSERT INTO t(i, t, u) VALUES (1, 'info for alice', 'alice'); RESET SESSION AUTHORIZATION; CREATE ROLE bob; GRANT CREATE ON SCHEMA public TO bob; ALTER TABLE t OWNER TO bob; GRANT SELECT ON TABLE tp_00 TO bob; SET SESSION AUTHORIZATION bob; SELECT * FROM tp_00; --- here bob can see his info only \d Schema | Name | Type | Owner --------+-------+-------------------+------- public | t | partitioned table | bob public | tp_00 | table | alice public | tp_10 | table | alice -- but then bob can do: ALTER TABLE t MERGE PARTITIONS (tp_00, tp_10) INTO tp_00; -- (yes, he also can detach the partition tp_00, but then he couldn't -- re-attach nor read it) \d Schema | Name | Type | Owner --------+-------+-------------------+------- public | t | partitioned table | bob public | tp_00 | table | bob Thus bob effectively have captured the partition with the data. What do you think, does this create a new security risk? Best regards, Alexander