2005-07-07 22:40:02 +02:00
|
|
|
--
|
|
|
|
-- DEPENDENCIES
|
|
|
|
--
|
2016-07-18 00:42:31 +02:00
|
|
|
CREATE USER regress_dep_user;
|
|
|
|
CREATE USER regress_dep_user2;
|
|
|
|
CREATE USER regress_dep_user3;
|
|
|
|
CREATE GROUP regress_dep_group;
|
2005-08-04 03:09:29 +02:00
|
|
|
CREATE TABLE deptest (f1 serial primary key, f2 text);
|
2016-07-18 00:42:31 +02:00
|
|
|
GRANT SELECT ON TABLE deptest TO GROUP regress_dep_group;
|
|
|
|
GRANT ALL ON TABLE deptest TO regress_dep_user, regress_dep_user2;
|
2005-07-07 22:40:02 +02:00
|
|
|
-- can't drop neither because they have privileges somewhere
|
2016-07-18 00:42:31 +02:00
|
|
|
DROP USER regress_dep_user;
|
|
|
|
ERROR: role "regress_dep_user" cannot be dropped because some objects depend on it
|
2010-08-26 21:49:08 +02:00
|
|
|
DETAIL: privileges for table deptest
|
2016-07-18 00:42:31 +02:00
|
|
|
DROP GROUP regress_dep_group;
|
|
|
|
ERROR: role "regress_dep_group" cannot be dropped because some objects depend on it
|
2010-08-26 21:49:08 +02:00
|
|
|
DETAIL: privileges for table deptest
|
2005-07-07 22:40:02 +02:00
|
|
|
-- if we revoke the privileges we can drop the group
|
2016-07-18 00:42:31 +02:00
|
|
|
REVOKE SELECT ON deptest FROM GROUP regress_dep_group;
|
|
|
|
DROP GROUP regress_dep_group;
|
2005-07-07 22:40:02 +02:00
|
|
|
-- can't drop the user if we revoke the privileges partially
|
2016-07-18 00:42:31 +02:00
|
|
|
REVOKE SELECT, INSERT, UPDATE, DELETE, TRUNCATE, REFERENCES ON deptest FROM regress_dep_user;
|
|
|
|
DROP USER regress_dep_user;
|
|
|
|
ERROR: role "regress_dep_user" cannot be dropped because some objects depend on it
|
2010-08-26 21:49:08 +02:00
|
|
|
DETAIL: privileges for table deptest
|
2005-07-07 22:40:02 +02:00
|
|
|
-- now we are OK to drop him
|
2016-07-18 00:42:31 +02:00
|
|
|
REVOKE TRIGGER ON deptest FROM regress_dep_user;
|
|
|
|
DROP USER regress_dep_user;
|
2005-07-07 22:40:02 +02:00
|
|
|
-- we are OK too if we drop the privileges all at once
|
2016-07-18 00:42:31 +02:00
|
|
|
REVOKE ALL ON deptest FROM regress_dep_user2;
|
|
|
|
DROP USER regress_dep_user2;
|
2005-07-07 22:40:02 +02:00
|
|
|
-- can't drop the owner of an object
|
2005-08-04 03:09:29 +02:00
|
|
|
-- the error message detail here would include a pg_toast_nnn name that
|
|
|
|
-- is not constant, so suppress it
|
|
|
|
\set VERBOSITY terse
|
2016-07-18 00:42:31 +02:00
|
|
|
ALTER TABLE deptest OWNER TO regress_dep_user3;
|
|
|
|
DROP USER regress_dep_user3;
|
|
|
|
ERROR: role "regress_dep_user3" cannot be dropped because some objects depend on it
|
2005-11-21 13:49:33 +01:00
|
|
|
\set VERBOSITY default
|
2005-07-07 22:40:02 +02:00
|
|
|
-- if we drop the object, we can drop the user too
|
|
|
|
DROP TABLE deptest;
|
2016-07-18 00:42:31 +02:00
|
|
|
DROP USER regress_dep_user3;
|
2005-11-21 13:49:33 +01:00
|
|
|
-- Test DROP OWNED
|
2016-07-18 00:42:31 +02:00
|
|
|
CREATE USER regress_dep_user0;
|
|
|
|
CREATE USER regress_dep_user1;
|
|
|
|
CREATE USER regress_dep_user2;
|
|
|
|
SET SESSION AUTHORIZATION regress_dep_user0;
|
2005-11-21 13:49:33 +01:00
|
|
|
-- permission denied
|
2016-07-18 00:42:31 +02:00
|
|
|
DROP OWNED BY regress_dep_user1;
|
2005-11-21 13:49:33 +01:00
|
|
|
ERROR: permission denied to drop objects
|
2016-07-18 00:42:31 +02:00
|
|
|
DROP OWNED BY regress_dep_user0, regress_dep_user2;
|
2005-11-21 13:49:33 +01:00
|
|
|
ERROR: permission denied to drop objects
|
2016-07-18 00:42:31 +02:00
|
|
|
REASSIGN OWNED BY regress_dep_user0 TO regress_dep_user1;
|
2005-11-21 13:49:33 +01:00
|
|
|
ERROR: permission denied to reassign objects
|
2016-07-18 00:42:31 +02:00
|
|
|
REASSIGN OWNED BY regress_dep_user1 TO regress_dep_user0;
|
2005-11-21 13:49:33 +01:00
|
|
|
ERROR: permission denied to reassign objects
|
|
|
|
-- this one is allowed
|
2016-07-18 00:42:31 +02:00
|
|
|
DROP OWNED BY regress_dep_user0;
|
2006-08-21 02:57:26 +02:00
|
|
|
CREATE TABLE deptest1 (f1 int unique);
|
2016-07-18 00:42:31 +02:00
|
|
|
GRANT ALL ON deptest1 TO regress_dep_user1 WITH GRANT OPTION;
|
|
|
|
SET SESSION AUTHORIZATION regress_dep_user1;
|
2005-11-21 13:49:33 +01:00
|
|
|
CREATE TABLE deptest (a serial primary key, b text);
|
2016-07-18 00:42:31 +02:00
|
|
|
GRANT ALL ON deptest1 TO regress_dep_user2;
|
2005-11-21 13:49:33 +01:00
|
|
|
RESET SESSION AUTHORIZATION;
|
|
|
|
\z deptest1
|
2016-07-18 00:42:31 +02:00
|
|
|
Access privileges
|
|
|
|
Schema | Name | Type | Access privileges | Column privileges | Policies
|
|
|
|
--------+----------+-------+----------------------------------------------------+-------------------+----------
|
|
|
|
public | deptest1 | table | regress_dep_user0=arwdDxt/regress_dep_user0 +| |
|
|
|
|
| | | regress_dep_user1=a*r*w*d*D*x*t*/regress_dep_user0+| |
|
|
|
|
| | | regress_dep_user2=arwdDxt/regress_dep_user1 | |
|
2005-11-21 13:49:33 +01:00
|
|
|
(1 row)
|
|
|
|
|
2016-07-18 00:42:31 +02:00
|
|
|
DROP OWNED BY regress_dep_user1;
|
2005-11-21 13:49:33 +01:00
|
|
|
-- all grants revoked
|
|
|
|
\z deptest1
|
2016-07-18 00:42:31 +02:00
|
|
|
Access privileges
|
|
|
|
Schema | Name | Type | Access privileges | Column privileges | Policies
|
|
|
|
--------+----------+-------+---------------------------------------------+-------------------+----------
|
|
|
|
public | deptest1 | table | regress_dep_user0=arwdDxt/regress_dep_user0 | |
|
2005-11-21 13:49:33 +01:00
|
|
|
(1 row)
|
|
|
|
|
|
|
|
-- table was dropped
|
|
|
|
\d deptest
|
|
|
|
-- Test REASSIGN OWNED
|
2016-07-18 00:42:31 +02:00
|
|
|
GRANT ALL ON deptest1 TO regress_dep_user1;
|
|
|
|
GRANT CREATE ON DATABASE regression TO regress_dep_user1;
|
|
|
|
SET SESSION AUTHORIZATION regress_dep_user1;
|
Rework internals of changing a type's ownership
This is necessary so that REASSIGN OWNED does the right thing with
composite types, to wit, that it also alters ownership of the type's
pg_class entry -- previously, the pg_class entry remained owned by the
original user, which caused later other failures such as the new owner's
inability to use ALTER TYPE to rename an attribute of the affected
composite. Also, if the original owner is later dropped, the pg_class
entry becomes owned by a non-existant user which is bogus.
To fix, create a new routine AlterTypeOwner_oid which knows whether to
pass the request to ATExecChangeOwner or deal with it directly, and use
that in shdepReassignOwner rather than calling AlterTypeOwnerInternal
directly. AlterTypeOwnerInternal is now simpler in that it only
modifies the pg_type entry and recurses to handle a possible array type;
higher-level tasks are handled by either AlterTypeOwner directly or
AlterTypeOwner_oid.
I took the opportunity to add a few more objects to the test rig for
REASSIGN OWNED, so that more cases are exercised. Additional ones could
be added for superuser-only-ownable objects (such as FDWs and event
triggers) but I didn't want to push my luck by adding a new superuser to
the tests on a backpatchable bug fix.
Per bug #13666 reported by Chris Pacejo.
Backpatch to 9.5.
(I would back-patch this all the way back, except that it doesn't apply
cleanly in 9.4 and earlier because 59367fdf9 wasn't backpatched. If we
decide that we need this in earlier branches too, we should backpatch
both.)
2015-12-17 18:25:41 +01:00
|
|
|
CREATE SCHEMA deptest;
|
2005-11-21 13:49:33 +01:00
|
|
|
CREATE TABLE deptest (a serial primary key, b text);
|
2016-07-18 00:42:31 +02:00
|
|
|
ALTER DEFAULT PRIVILEGES FOR ROLE regress_dep_user1 IN SCHEMA deptest
|
|
|
|
GRANT ALL ON TABLES TO regress_dep_user2;
|
Rework internals of changing a type's ownership
This is necessary so that REASSIGN OWNED does the right thing with
composite types, to wit, that it also alters ownership of the type's
pg_class entry -- previously, the pg_class entry remained owned by the
original user, which caused later other failures such as the new owner's
inability to use ALTER TYPE to rename an attribute of the affected
composite. Also, if the original owner is later dropped, the pg_class
entry becomes owned by a non-existant user which is bogus.
To fix, create a new routine AlterTypeOwner_oid which knows whether to
pass the request to ATExecChangeOwner or deal with it directly, and use
that in shdepReassignOwner rather than calling AlterTypeOwnerInternal
directly. AlterTypeOwnerInternal is now simpler in that it only
modifies the pg_type entry and recurses to handle a possible array type;
higher-level tasks are handled by either AlterTypeOwner directly or
AlterTypeOwner_oid.
I took the opportunity to add a few more objects to the test rig for
REASSIGN OWNED, so that more cases are exercised. Additional ones could
be added for superuser-only-ownable objects (such as FDWs and event
triggers) but I didn't want to push my luck by adding a new superuser to
the tests on a backpatchable bug fix.
Per bug #13666 reported by Chris Pacejo.
Backpatch to 9.5.
(I would back-patch this all the way back, except that it doesn't apply
cleanly in 9.4 and earlier because 59367fdf9 wasn't backpatched. If we
decide that we need this in earlier branches too, we should backpatch
both.)
2015-12-17 18:25:41 +01:00
|
|
|
CREATE FUNCTION deptest_func() RETURNS void LANGUAGE plpgsql
|
|
|
|
AS $$ BEGIN END; $$;
|
|
|
|
CREATE TYPE deptest_enum AS ENUM ('red');
|
|
|
|
CREATE TYPE deptest_range AS RANGE (SUBTYPE = int4);
|
2006-08-21 02:57:26 +02:00
|
|
|
CREATE TABLE deptest2 (f1 int);
|
|
|
|
-- make a serial column the hard way
|
|
|
|
CREATE SEQUENCE ss1;
|
|
|
|
ALTER TABLE deptest2 ALTER f1 SET DEFAULT nextval('ss1');
|
|
|
|
ALTER SEQUENCE ss1 OWNED BY deptest2.f1;
|
Rework internals of changing a type's ownership
This is necessary so that REASSIGN OWNED does the right thing with
composite types, to wit, that it also alters ownership of the type's
pg_class entry -- previously, the pg_class entry remained owned by the
original user, which caused later other failures such as the new owner's
inability to use ALTER TYPE to rename an attribute of the affected
composite. Also, if the original owner is later dropped, the pg_class
entry becomes owned by a non-existant user which is bogus.
To fix, create a new routine AlterTypeOwner_oid which knows whether to
pass the request to ATExecChangeOwner or deal with it directly, and use
that in shdepReassignOwner rather than calling AlterTypeOwnerInternal
directly. AlterTypeOwnerInternal is now simpler in that it only
modifies the pg_type entry and recurses to handle a possible array type;
higher-level tasks are handled by either AlterTypeOwner directly or
AlterTypeOwner_oid.
I took the opportunity to add a few more objects to the test rig for
REASSIGN OWNED, so that more cases are exercised. Additional ones could
be added for superuser-only-ownable objects (such as FDWs and event
triggers) but I didn't want to push my luck by adding a new superuser to
the tests on a backpatchable bug fix.
Per bug #13666 reported by Chris Pacejo.
Backpatch to 9.5.
(I would back-patch this all the way back, except that it doesn't apply
cleanly in 9.4 and earlier because 59367fdf9 wasn't backpatched. If we
decide that we need this in earlier branches too, we should backpatch
both.)
2015-12-17 18:25:41 +01:00
|
|
|
-- When reassigning ownership of a composite type, its pg_class entry
|
|
|
|
-- should match
|
|
|
|
CREATE TYPE deptest_t AS (a int);
|
|
|
|
SELECT typowner = relowner
|
|
|
|
FROM pg_type JOIN pg_class c ON typrelid = c.oid WHERE typname = 'deptest_t';
|
|
|
|
?column?
|
|
|
|
----------
|
|
|
|
t
|
|
|
|
(1 row)
|
|
|
|
|
2005-11-21 13:49:33 +01:00
|
|
|
RESET SESSION AUTHORIZATION;
|
2016-07-18 00:42:31 +02:00
|
|
|
REASSIGN OWNED BY regress_dep_user1 TO regress_dep_user2;
|
2005-11-21 13:49:33 +01:00
|
|
|
\dt deptest
|
|
|
|
List of relations
|
2016-07-18 00:42:31 +02:00
|
|
|
Schema | Name | Type | Owner
|
|
|
|
--------+---------+-------+-------------------
|
|
|
|
public | deptest | table | regress_dep_user2
|
2005-11-21 13:49:33 +01:00
|
|
|
(1 row)
|
|
|
|
|
Rework internals of changing a type's ownership
This is necessary so that REASSIGN OWNED does the right thing with
composite types, to wit, that it also alters ownership of the type's
pg_class entry -- previously, the pg_class entry remained owned by the
original user, which caused later other failures such as the new owner's
inability to use ALTER TYPE to rename an attribute of the affected
composite. Also, if the original owner is later dropped, the pg_class
entry becomes owned by a non-existant user which is bogus.
To fix, create a new routine AlterTypeOwner_oid which knows whether to
pass the request to ATExecChangeOwner or deal with it directly, and use
that in shdepReassignOwner rather than calling AlterTypeOwnerInternal
directly. AlterTypeOwnerInternal is now simpler in that it only
modifies the pg_type entry and recurses to handle a possible array type;
higher-level tasks are handled by either AlterTypeOwner directly or
AlterTypeOwner_oid.
I took the opportunity to add a few more objects to the test rig for
REASSIGN OWNED, so that more cases are exercised. Additional ones could
be added for superuser-only-ownable objects (such as FDWs and event
triggers) but I didn't want to push my luck by adding a new superuser to
the tests on a backpatchable bug fix.
Per bug #13666 reported by Chris Pacejo.
Backpatch to 9.5.
(I would back-patch this all the way back, except that it doesn't apply
cleanly in 9.4 and earlier because 59367fdf9 wasn't backpatched. If we
decide that we need this in earlier branches too, we should backpatch
both.)
2015-12-17 18:25:41 +01:00
|
|
|
SELECT typowner = relowner
|
|
|
|
FROM pg_type JOIN pg_class c ON typrelid = c.oid WHERE typname = 'deptest_t';
|
|
|
|
?column?
|
|
|
|
----------
|
|
|
|
t
|
|
|
|
(1 row)
|
|
|
|
|
2005-11-21 13:49:33 +01:00
|
|
|
-- doesn't work: grant still exists
|
2016-07-18 00:42:31 +02:00
|
|
|
DROP USER regress_dep_user1;
|
|
|
|
ERROR: role "regress_dep_user1" cannot be dropped because some objects depend on it
|
2019-03-24 23:17:41 +01:00
|
|
|
DETAIL: privileges for database regression
|
|
|
|
privileges for table deptest1
|
Make heap TID a tiebreaker nbtree index column.
Make nbtree treat all index tuples as having a heap TID attribute.
Index searches can distinguish duplicates by heap TID, since heap TID is
always guaranteed to be unique. This general approach has numerous
benefits for performance, and is prerequisite to teaching VACUUM to
perform "retail index tuple deletion".
Naively adding a new attribute to every pivot tuple has unacceptable
overhead (it bloats internal pages), so suffix truncation of pivot
tuples is added. This will usually truncate away the "extra" heap TID
attribute from pivot tuples during a leaf page split, and may also
truncate away additional user attributes. This can increase fan-out,
especially in a multi-column index. Truncation can only occur at the
attribute granularity, which isn't particularly effective, but works
well enough for now. A future patch may add support for truncating
"within" text attributes by generating truncated key values using new
opclass infrastructure.
Only new indexes (BTREE_VERSION 4 indexes) will have insertions that
treat heap TID as a tiebreaker attribute, or will have pivot tuples
undergo suffix truncation during a leaf page split (on-disk
compatibility with versions 2 and 3 is preserved). Upgrades to version
4 cannot be performed on-the-fly, unlike upgrades from version 2 to
version 3. contrib/amcheck continues to work with version 2 and 3
indexes, while also enforcing stricter invariants when verifying version
4 indexes. These stricter invariants are the same invariants described
by "3.1.12 Sequencing" from the Lehman and Yao paper.
A later patch will enhance the logic used by nbtree to pick a split
point. This patch is likely to negatively impact performance without
smarter choices around the precise point to split leaf pages at. Making
these two mostly-distinct sets of enhancements into distinct commits
seems like it might clarify their design, even though neither commit is
particularly useful on its own.
The maximum allowed size of new tuples is reduced by an amount equal to
the space required to store an extra MAXALIGN()'d TID in a new high key
during leaf page splits. The user-facing definition of the "1/3 of a
page" restriction is already imprecise, and so does not need to be
revised. However, there should be a compatibility note in the v12
release notes.
Author: Peter Geoghegan
Reviewed-By: Heikki Linnakangas, Alexander Korotkov
Discussion: https://postgr.es/m/CAH2-WzkVb0Kom=R+88fDFb=JSxZMFvbHVC6Mn9LJ2n=X=kS-Uw@mail.gmail.com
2019-03-20 18:04:01 +01:00
|
|
|
owner of default privileges on new relations belonging to role regress_dep_user1 in schema deptest
|
2016-07-18 00:42:31 +02:00
|
|
|
DROP OWNED BY regress_dep_user1;
|
|
|
|
DROP USER regress_dep_user1;
|
|
|
|
DROP USER regress_dep_user2;
|
|
|
|
ERROR: role "regress_dep_user2" cannot be dropped because some objects depend on it
|
2019-03-25 00:15:37 +01:00
|
|
|
DETAIL: owner of schema deptest
|
|
|
|
owner of sequence deptest_a_seq
|
|
|
|
owner of table deptest
|
|
|
|
owner of function deptest_func()
|
|
|
|
owner of type deptest_enum
|
|
|
|
owner of type deptest_range
|
|
|
|
owner of table deptest2
|
|
|
|
owner of sequence ss1
|
|
|
|
owner of type deptest_t
|
2016-07-18 00:42:31 +02:00
|
|
|
DROP OWNED BY regress_dep_user2, regress_dep_user0;
|
|
|
|
DROP USER regress_dep_user2;
|
|
|
|
DROP USER regress_dep_user0;
|