2008-12-19 17:25:19 +01:00
--
-- Test foreign-data wrapper and server management.
--
-- Clean up in case a prior regression run failed
-- Suppress NOTICE messages when roles don't exist
2016-07-18 00:42:31 +02:00
SET client_min_messages TO 'warning';
DROP ROLE IF EXISTS regress_foreign_data_user, regress_test_role, regress_test_role2, regress_test_role_super, regress_test_indirect, regress_unprivileged_role;
2008-12-19 17:25:19 +01:00
RESET client_min_messages;
2016-07-18 00:42:31 +02:00
CREATE ROLE regress_foreign_data_user LOGIN SUPERUSER;
SET SESSION AUTHORIZATION 'regress_foreign_data_user';
2008-12-19 17:25:19 +01:00
CREATE ROLE regress_test_role;
CREATE ROLE regress_test_role2;
CREATE ROLE regress_test_role_super SUPERUSER;
CREATE ROLE regress_test_indirect;
2016-07-18 00:42:31 +02:00
CREATE ROLE regress_unprivileged_role;
2009-02-24 11:06:36 +01:00
CREATE FOREIGN DATA WRAPPER dummy;
2011-04-01 17:28:28 +02:00
COMMENT ON FOREIGN DATA WRAPPER dummy IS 'useless';
2009-02-24 11:06:36 +01:00
CREATE FOREIGN DATA WRAPPER postgresql VALIDATOR postgresql_fdw_validator;
2008-12-19 17:25:19 +01:00
-- At this point we should have 2 built-in wrappers and no servers.
2011-02-19 06:06:18 +01:00
SELECT fdwname, fdwhandler::regproc, fdwvalidator::regproc, fdwoptions FROM pg_foreign_data_wrapper ORDER BY 1, 2, 3;
fdwname | fdwhandler | fdwvalidator | fdwoptions
------------+------------+--------------------------+------------
dummy | - | - |
postgresql | - | postgresql_fdw_validator |
2008-12-19 17:25:19 +01:00
(2 rows)
SELECT srvname, srvoptions FROM pg_foreign_server;
srvname | srvoptions
---------+------------
(0 rows)
SELECT * FROM pg_user_mapping;
umuser | umserver | umoptions
--------+----------+-----------
(0 rows)
-- CREATE FOREIGN DATA WRAPPER
2009-02-24 11:06:36 +01:00
CREATE FOREIGN DATA WRAPPER foo VALIDATOR bar; -- ERROR
ERROR: function bar(text[], oid) does not exist
CREATE FOREIGN DATA WRAPPER foo;
2008-12-19 17:25:19 +01:00
\dew
2016-07-18 00:42:31 +02:00
List of foreign-data wrappers
Name | Owner | Handler | Validator
------------+---------------------------+---------+--------------------------
dummy | regress_foreign_data_user | - | -
foo | regress_foreign_data_user | - | -
postgresql | regress_foreign_data_user | - | postgresql_fdw_validator
2008-12-19 17:25:19 +01:00
(3 rows)
2009-02-24 11:06:36 +01:00
CREATE FOREIGN DATA WRAPPER foo; -- duplicate
2008-12-19 17:25:19 +01:00
ERROR: foreign-data wrapper "foo" already exists
DROP FOREIGN DATA WRAPPER foo;
2009-02-24 11:06:36 +01:00
CREATE FOREIGN DATA WRAPPER foo OPTIONS (testing '1');
2008-12-19 17:25:19 +01:00
\dew+
2016-07-18 00:42:31 +02:00
List of foreign-data wrappers
Name | Owner | Handler | Validator | Access privileges | FDW Options | Description
------------+---------------------------+---------+--------------------------+-------------------+---------------+-------------
dummy | regress_foreign_data_user | - | - | | | useless
foo | regress_foreign_data_user | - | - | | (testing '1') |
postgresql | regress_foreign_data_user | - | postgresql_fdw_validator | | |
2008-12-19 17:25:19 +01:00
(3 rows)
DROP FOREIGN DATA WRAPPER foo;
2009-02-24 11:06:36 +01:00
CREATE FOREIGN DATA WRAPPER foo OPTIONS (testing '1', testing '2'); -- ERROR
2008-12-19 17:25:19 +01:00
ERROR: option "testing" provided more than once
2009-02-24 11:06:36 +01:00
CREATE FOREIGN DATA WRAPPER foo OPTIONS (testing '1', another '2');
2008-12-19 17:25:19 +01:00
\dew+
2016-07-18 00:42:31 +02:00
List of foreign-data wrappers
Name | Owner | Handler | Validator | Access privileges | FDW Options | Description
------------+---------------------------+---------+--------------------------+-------------------+----------------------------+-------------
dummy | regress_foreign_data_user | - | - | | | useless
foo | regress_foreign_data_user | - | - | | (testing '1', another '2') |
postgresql | regress_foreign_data_user | - | postgresql_fdw_validator | | |
2008-12-19 17:25:19 +01:00
(3 rows)
DROP FOREIGN DATA WRAPPER foo;
SET ROLE regress_test_role;
2009-02-24 11:06:36 +01:00
CREATE FOREIGN DATA WRAPPER foo; -- ERROR
2008-12-19 17:25:19 +01:00
ERROR: permission denied to create foreign-data wrapper "foo"
HINT: Must be superuser to create a foreign-data wrapper.
RESET ROLE;
2009-02-24 11:06:36 +01:00
CREATE FOREIGN DATA WRAPPER foo VALIDATOR postgresql_fdw_validator;
2008-12-19 17:25:19 +01:00
\dew+
2016-07-18 00:42:31 +02:00
List of foreign-data wrappers
Name | Owner | Handler | Validator | Access privileges | FDW Options | Description
------------+---------------------------+---------+--------------------------+-------------------+-------------+-------------
dummy | regress_foreign_data_user | - | - | | | useless
foo | regress_foreign_data_user | - | postgresql_fdw_validator | | |
postgresql | regress_foreign_data_user | - | postgresql_fdw_validator | | |
2008-12-19 17:25:19 +01:00
(3 rows)
-- ALTER FOREIGN DATA WRAPPER
2009-02-24 11:06:36 +01:00
ALTER FOREIGN DATA WRAPPER foo; -- ERROR
ERROR: syntax error at or near ";"
LINE 1: ALTER FOREIGN DATA WRAPPER foo;
^
ALTER FOREIGN DATA WRAPPER foo VALIDATOR bar; -- ERROR
ERROR: function bar(text[], oid) does not exist
ALTER FOREIGN DATA WRAPPER foo NO VALIDATOR;
2008-12-19 17:25:19 +01:00
\dew+
2016-07-18 00:42:31 +02:00
List of foreign-data wrappers
Name | Owner | Handler | Validator | Access privileges | FDW Options | Description
------------+---------------------------+---------+--------------------------+-------------------+-------------+-------------
dummy | regress_foreign_data_user | - | - | | | useless
foo | regress_foreign_data_user | - | - | | |
postgresql | regress_foreign_data_user | - | postgresql_fdw_validator | | |
2008-12-19 17:25:19 +01:00
(3 rows)
ALTER FOREIGN DATA WRAPPER foo OPTIONS (a '1', b '2');
ALTER FOREIGN DATA WRAPPER foo OPTIONS (SET c '4'); -- ERROR
ERROR: option "c" not found
ALTER FOREIGN DATA WRAPPER foo OPTIONS (DROP c); -- ERROR
ERROR: option "c" not found
ALTER FOREIGN DATA WRAPPER foo OPTIONS (ADD x '1', DROP x);
\dew+
2016-07-18 00:42:31 +02:00
List of foreign-data wrappers
Name | Owner | Handler | Validator | Access privileges | FDW Options | Description
------------+---------------------------+---------+--------------------------+-------------------+----------------+-------------
dummy | regress_foreign_data_user | - | - | | | useless
foo | regress_foreign_data_user | - | - | | (a '1', b '2') |
postgresql | regress_foreign_data_user | - | postgresql_fdw_validator | | |
2008-12-19 17:25:19 +01:00
(3 rows)
ALTER FOREIGN DATA WRAPPER foo OPTIONS (DROP a, SET b '3', ADD c '4');
\dew+
2016-07-18 00:42:31 +02:00
List of foreign-data wrappers
Name | Owner | Handler | Validator | Access privileges | FDW Options | Description
------------+---------------------------+---------+--------------------------+-------------------+----------------+-------------
dummy | regress_foreign_data_user | - | - | | | useless
foo | regress_foreign_data_user | - | - | | (b '3', c '4') |
postgresql | regress_foreign_data_user | - | postgresql_fdw_validator | | |
2008-12-19 17:25:19 +01:00
(3 rows)
ALTER FOREIGN DATA WRAPPER foo OPTIONS (a '2');
ALTER FOREIGN DATA WRAPPER foo OPTIONS (b '4'); -- ERROR
ERROR: option "b" provided more than once
\dew+
2016-07-18 00:42:31 +02:00
List of foreign-data wrappers
Name | Owner | Handler | Validator | Access privileges | FDW Options | Description
------------+---------------------------+---------+--------------------------+-------------------+-----------------------+-------------
dummy | regress_foreign_data_user | - | - | | | useless
foo | regress_foreign_data_user | - | - | | (b '3', c '4', a '2') |
postgresql | regress_foreign_data_user | - | postgresql_fdw_validator | | |
2008-12-19 17:25:19 +01:00
(3 rows)
SET ROLE regress_test_role;
ALTER FOREIGN DATA WRAPPER foo OPTIONS (ADD d '5'); -- ERROR
ERROR: permission denied to alter foreign-data wrapper "foo"
HINT: Must be superuser to alter a foreign-data wrapper.
SET ROLE regress_test_role_super;
ALTER FOREIGN DATA WRAPPER foo OPTIONS (ADD d '5');
\dew+
2016-07-18 00:42:31 +02:00
List of foreign-data wrappers
Name | Owner | Handler | Validator | Access privileges | FDW Options | Description
------------+---------------------------+---------+--------------------------+-------------------+------------------------------+-------------
dummy | regress_foreign_data_user | - | - | | | useless
foo | regress_foreign_data_user | - | - | | (b '3', c '4', a '2', d '5') |
postgresql | regress_foreign_data_user | - | postgresql_fdw_validator | | |
2008-12-19 17:25:19 +01:00
(3 rows)
ALTER FOREIGN DATA WRAPPER foo OWNER TO regress_test_role; -- ERROR
ERROR: permission denied to change owner of foreign-data wrapper "foo"
HINT: The owner of a foreign-data wrapper must be a superuser.
ALTER FOREIGN DATA WRAPPER foo OWNER TO regress_test_role_super;
ALTER ROLE regress_test_role_super NOSUPERUSER;
SET ROLE regress_test_role_super;
ALTER FOREIGN DATA WRAPPER foo OPTIONS (ADD e '6'); -- ERROR
ERROR: permission denied to alter foreign-data wrapper "foo"
HINT: Must be superuser to alter a foreign-data wrapper.
RESET ROLE;
\dew+
2016-07-18 00:42:31 +02:00
List of foreign-data wrappers
Name | Owner | Handler | Validator | Access privileges | FDW Options | Description
------------+---------------------------+---------+--------------------------+-------------------+------------------------------+-------------
dummy | regress_foreign_data_user | - | - | | | useless
foo | regress_test_role_super | - | - | | (b '3', c '4', a '2', d '5') |
postgresql | regress_foreign_data_user | - | postgresql_fdw_validator | | |
2008-12-19 17:25:19 +01:00
(3 rows)
2011-12-09 19:42:30 +01:00
ALTER FOREIGN DATA WRAPPER foo RENAME TO foo1;
\dew+
2016-07-18 00:42:31 +02:00
List of foreign-data wrappers
Name | Owner | Handler | Validator | Access privileges | FDW Options | Description
------------+---------------------------+---------+--------------------------+-------------------+------------------------------+-------------
dummy | regress_foreign_data_user | - | - | | | useless
foo1 | regress_test_role_super | - | - | | (b '3', c '4', a '2', d '5') |
postgresql | regress_foreign_data_user | - | postgresql_fdw_validator | | |
2011-12-09 19:42:30 +01:00
(3 rows)
ALTER FOREIGN DATA WRAPPER foo1 RENAME TO foo;
2008-12-19 17:25:19 +01:00
-- DROP FOREIGN DATA WRAPPER
DROP FOREIGN DATA WRAPPER nonexistent; -- ERROR
ERROR: foreign-data wrapper "nonexistent" does not exist
DROP FOREIGN DATA WRAPPER IF EXISTS nonexistent;
NOTICE: foreign-data wrapper "nonexistent" does not exist, skipping
\dew+
2016-07-18 00:42:31 +02:00
List of foreign-data wrappers
Name | Owner | Handler | Validator | Access privileges | FDW Options | Description
------------+---------------------------+---------+--------------------------+-------------------+------------------------------+-------------
dummy | regress_foreign_data_user | - | - | | | useless
foo | regress_test_role_super | - | - | | (b '3', c '4', a '2', d '5') |
postgresql | regress_foreign_data_user | - | postgresql_fdw_validator | | |
2008-12-19 17:25:19 +01:00
(3 rows)
DROP ROLE regress_test_role_super; -- ERROR
ERROR: role "regress_test_role_super" cannot be dropped because some objects depend on it
DETAIL: owner of foreign-data wrapper foo
SET ROLE regress_test_role_super;
DROP FOREIGN DATA WRAPPER foo;
2011-11-18 03:31:29 +01:00
RESET ROLE;
2011-12-16 00:45:02 +01:00
DROP ROLE regress_test_role_super;
2008-12-19 17:25:19 +01:00
\dew+
2016-07-18 00:42:31 +02:00
List of foreign-data wrappers
Name | Owner | Handler | Validator | Access privileges | FDW Options | Description
------------+---------------------------+---------+--------------------------+-------------------+-------------+-------------
dummy | regress_foreign_data_user | - | - | | | useless
postgresql | regress_foreign_data_user | - | postgresql_fdw_validator | | |
2008-12-19 17:25:19 +01:00
(2 rows)
2009-02-24 11:06:36 +01:00
CREATE FOREIGN DATA WRAPPER foo;
2008-12-19 17:25:19 +01:00
CREATE SERVER s1 FOREIGN DATA WRAPPER foo;
2011-04-01 17:28:28 +02:00
COMMENT ON SERVER s1 IS 'foreign server';
2008-12-19 17:25:19 +01:00
CREATE USER MAPPING FOR current_user SERVER s1;
\dew+
2016-07-18 00:42:31 +02:00
List of foreign-data wrappers
Name | Owner | Handler | Validator | Access privileges | FDW Options | Description
------------+---------------------------+---------+--------------------------+-------------------+-------------+-------------
dummy | regress_foreign_data_user | - | - | | | useless
foo | regress_foreign_data_user | - | - | | |
postgresql | regress_foreign_data_user | - | postgresql_fdw_validator | | |
2008-12-19 17:25:19 +01:00
(3 rows)
\des+
2016-07-18 00:42:31 +02:00
List of foreign servers
Name | Owner | Foreign-data wrapper | Access privileges | Type | Version | FDW Options | Description
------+---------------------------+----------------------+-------------------+------+---------+-------------+----------------
s1 | regress_foreign_data_user | foo | | | | | foreign server
2008-12-19 17:25:19 +01:00
(1 row)
\deu+
2016-07-18 00:42:31 +02:00
List of user mappings
Server | User name | FDW Options
--------+---------------------------+-------------
s1 | regress_foreign_data_user |
2008-12-19 17:25:19 +01:00
(1 row)
DROP FOREIGN DATA WRAPPER foo; -- ERROR
ERROR: cannot drop foreign-data wrapper foo because other objects depend on it
DETAIL: server s1 depends on foreign-data wrapper foo
2016-07-18 00:42:31 +02:00
user mapping for regress_foreign_data_user on server s1 depends on server s1
2008-12-19 17:25:19 +01:00
HINT: Use DROP ... CASCADE to drop the dependent objects too.
SET ROLE regress_test_role;
DROP FOREIGN DATA WRAPPER foo CASCADE; -- ERROR
2011-11-18 03:31:29 +01:00
ERROR: must be owner of foreign-data wrapper foo
2008-12-19 17:25:19 +01:00
RESET ROLE;
DROP FOREIGN DATA WRAPPER foo CASCADE;
NOTICE: drop cascades to 2 other objects
DETAIL: drop cascades to server s1
2016-07-18 00:42:31 +02:00
drop cascades to user mapping for regress_foreign_data_user on server s1
2008-12-19 17:25:19 +01:00
\dew+
2016-07-18 00:42:31 +02:00
List of foreign-data wrappers
Name | Owner | Handler | Validator | Access privileges | FDW Options | Description
------------+---------------------------+---------+--------------------------+-------------------+-------------+-------------
dummy | regress_foreign_data_user | - | - | | | useless
postgresql | regress_foreign_data_user | - | postgresql_fdw_validator | | |
2008-12-19 17:25:19 +01:00
(2 rows)
\des+
2011-08-11 17:45:47 +02:00
List of foreign servers
Name | Owner | Foreign-data wrapper | Access privileges | Type | Version | FDW Options | Description
------+-------+----------------------+-------------------+------+---------+-------------+-------------
2008-12-19 17:25:19 +01:00
(0 rows)
\deu+
2011-08-11 17:45:47 +02:00
List of user mappings
Server | User name | FDW Options
--------+-----------+-------------
2008-12-19 17:25:19 +01:00
(0 rows)
-- exercise CREATE SERVER
CREATE SERVER s1 FOREIGN DATA WRAPPER foo; -- ERROR
ERROR: foreign-data wrapper "foo" does not exist
2011-08-25 18:47:30 +02:00
CREATE FOREIGN DATA WRAPPER foo OPTIONS ("test wrapper" 'true');
2008-12-19 17:25:19 +01:00
CREATE SERVER s1 FOREIGN DATA WRAPPER foo;
CREATE SERVER s1 FOREIGN DATA WRAPPER foo; -- ERROR
ERROR: server "s1" already exists
CREATE SERVER s2 FOREIGN DATA WRAPPER foo OPTIONS (host 'a', dbname 'b');
CREATE SERVER s3 TYPE 'oracle' FOREIGN DATA WRAPPER foo;
CREATE SERVER s4 TYPE 'oracle' FOREIGN DATA WRAPPER foo OPTIONS (host 'a', dbname 'b');
CREATE SERVER s5 VERSION '15.0' FOREIGN DATA WRAPPER foo;
CREATE SERVER s6 VERSION '16.0' FOREIGN DATA WRAPPER foo OPTIONS (host 'a', dbname 'b');
CREATE SERVER s7 TYPE 'oracle' VERSION '17.0' FOREIGN DATA WRAPPER foo OPTIONS (host 'a', dbname 'b');
CREATE SERVER s8 FOREIGN DATA WRAPPER postgresql OPTIONS (foo '1'); -- ERROR
2009-02-24 11:06:36 +01:00
ERROR: invalid option "foo"
2009-12-23 13:23:59 +01:00
HINT: Valid options in this context are: authtype, service, connect_timeout, dbname, host, hostaddr, port, tty, options, requiressl, sslmode, gsslib
2008-12-19 17:25:19 +01:00
CREATE SERVER s8 FOREIGN DATA WRAPPER postgresql OPTIONS (host 'localhost', dbname 's8db');
\des+
2016-07-18 00:42:31 +02:00
List of foreign servers
Name | Owner | Foreign-data wrapper | Access privileges | Type | Version | FDW Options | Description
------+---------------------------+----------------------+-------------------+--------+---------+-----------------------------------+-------------
s1 | regress_foreign_data_user | foo | | | | |
s2 | regress_foreign_data_user | foo | | | | (host 'a', dbname 'b') |
s3 | regress_foreign_data_user | foo | | oracle | | |
s4 | regress_foreign_data_user | foo | | oracle | | (host 'a', dbname 'b') |
s5 | regress_foreign_data_user | foo | | | 15.0 | |
s6 | regress_foreign_data_user | foo | | | 16.0 | (host 'a', dbname 'b') |
s7 | regress_foreign_data_user | foo | | oracle | 17.0 | (host 'a', dbname 'b') |
s8 | regress_foreign_data_user | postgresql | | | | (host 'localhost', dbname 's8db') |
2009-01-09 15:50:00 +01:00
(8 rows)
2008-12-19 17:25:19 +01:00
SET ROLE regress_test_role;
2009-03-09 16:04:21 +01:00
CREATE SERVER t1 FOREIGN DATA WRAPPER foo; -- ERROR: no usage on FDW
2008-12-19 17:25:19 +01:00
ERROR: permission denied for foreign-data wrapper foo
RESET ROLE;
GRANT USAGE ON FOREIGN DATA WRAPPER foo TO regress_test_role;
SET ROLE regress_test_role;
2009-03-09 16:04:21 +01:00
CREATE SERVER t1 FOREIGN DATA WRAPPER foo;
2008-12-19 17:25:19 +01:00
RESET ROLE;
\des+
2016-07-18 00:42:31 +02:00
List of foreign servers
Name | Owner | Foreign-data wrapper | Access privileges | Type | Version | FDW Options | Description
------+---------------------------+----------------------+-------------------+--------+---------+-----------------------------------+-------------
s1 | regress_foreign_data_user | foo | | | | |
s2 | regress_foreign_data_user | foo | | | | (host 'a', dbname 'b') |
s3 | regress_foreign_data_user | foo | | oracle | | |
s4 | regress_foreign_data_user | foo | | oracle | | (host 'a', dbname 'b') |
s5 | regress_foreign_data_user | foo | | | 15.0 | |
s6 | regress_foreign_data_user | foo | | | 16.0 | (host 'a', dbname 'b') |
s7 | regress_foreign_data_user | foo | | oracle | 17.0 | (host 'a', dbname 'b') |
s8 | regress_foreign_data_user | postgresql | | | | (host 'localhost', dbname 's8db') |
t1 | regress_test_role | foo | | | | |
2009-01-09 15:50:00 +01:00
(9 rows)
2008-12-19 17:25:19 +01:00
REVOKE USAGE ON FOREIGN DATA WRAPPER foo FROM regress_test_role;
GRANT USAGE ON FOREIGN DATA WRAPPER foo TO regress_test_indirect;
SET ROLE regress_test_role;
2009-03-09 16:04:21 +01:00
CREATE SERVER t2 FOREIGN DATA WRAPPER foo; -- ERROR
2008-12-19 17:25:19 +01:00
ERROR: permission denied for foreign-data wrapper foo
RESET ROLE;
GRANT regress_test_indirect TO regress_test_role;
SET ROLE regress_test_role;
2009-03-09 16:04:21 +01:00
CREATE SERVER t2 FOREIGN DATA WRAPPER foo;
2008-12-19 17:25:19 +01:00
\des+
2016-07-18 00:42:31 +02:00
List of foreign servers
Name | Owner | Foreign-data wrapper | Access privileges | Type | Version | FDW Options | Description
------+---------------------------+----------------------+-------------------+--------+---------+-----------------------------------+-------------
s1 | regress_foreign_data_user | foo | | | | |
s2 | regress_foreign_data_user | foo | | | | (host 'a', dbname 'b') |
s3 | regress_foreign_data_user | foo | | oracle | | |
s4 | regress_foreign_data_user | foo | | oracle | | (host 'a', dbname 'b') |
s5 | regress_foreign_data_user | foo | | | 15.0 | |
s6 | regress_foreign_data_user | foo | | | 16.0 | (host 'a', dbname 'b') |
s7 | regress_foreign_data_user | foo | | oracle | 17.0 | (host 'a', dbname 'b') |
s8 | regress_foreign_data_user | postgresql | | | | (host 'localhost', dbname 's8db') |
t1 | regress_test_role | foo | | | | |
t2 | regress_test_role | foo | | | | |
2009-01-09 15:50:00 +01:00
(10 rows)
2008-12-19 17:25:19 +01:00
RESET ROLE;
REVOKE regress_test_indirect FROM regress_test_role;
-- ALTER SERVER
ALTER SERVER s0; -- ERROR
ERROR: syntax error at or near ";"
LINE 1: ALTER SERVER s0;
^
ALTER SERVER s0 OPTIONS (a '1'); -- ERROR
ERROR: server "s0" does not exist
ALTER SERVER s1 VERSION '1.0' OPTIONS (servername 's1');
ALTER SERVER s2 VERSION '1.1';
2011-08-25 18:47:30 +02:00
ALTER SERVER s3 OPTIONS ("tns name" 'orcl', port '1521');
2008-12-19 17:25:19 +01:00
GRANT USAGE ON FOREIGN SERVER s1 TO regress_test_role;
GRANT USAGE ON FOREIGN SERVER s6 TO regress_test_role2 WITH GRANT OPTION;
\des+
2016-07-18 00:42:31 +02:00
List of foreign servers
Name | Owner | Foreign-data wrapper | Access privileges | Type | Version | FDW Options | Description
------+---------------------------+----------------------+-------------------------------------------------------+--------+---------+-----------------------------------+-------------
s1 | regress_foreign_data_user | foo | regress_foreign_data_user=U/regress_foreign_data_user+| | 1.0 | (servername 's1') |
| | | regress_test_role=U/regress_foreign_data_user | | | |
s2 | regress_foreign_data_user | foo | | | 1.1 | (host 'a', dbname 'b') |
s3 | regress_foreign_data_user | foo | | oracle | | ("tns name" 'orcl', port '1521') |
s4 | regress_foreign_data_user | foo | | oracle | | (host 'a', dbname 'b') |
s5 | regress_foreign_data_user | foo | | | 15.0 | |
s6 | regress_foreign_data_user | foo | regress_foreign_data_user=U/regress_foreign_data_user+| | 16.0 | (host 'a', dbname 'b') |
| | | regress_test_role2=U*/regress_foreign_data_user | | | |
s7 | regress_foreign_data_user | foo | | oracle | 17.0 | (host 'a', dbname 'b') |
s8 | regress_foreign_data_user | postgresql | | | | (host 'localhost', dbname 's8db') |
t1 | regress_test_role | foo | | | | |
t2 | regress_test_role | foo | | | | |
2009-01-09 15:50:00 +01:00
(10 rows)
2008-12-19 17:25:19 +01:00
SET ROLE regress_test_role;
ALTER SERVER s1 VERSION '1.1'; -- ERROR
ERROR: must be owner of foreign server s1
ALTER SERVER s1 OWNER TO regress_test_role; -- ERROR
ERROR: must be owner of foreign server s1
RESET ROLE;
ALTER SERVER s1 OWNER TO regress_test_role;
GRANT regress_test_role2 TO regress_test_role;
SET ROLE regress_test_role;
ALTER SERVER s1 VERSION '1.1';
ALTER SERVER s1 OWNER TO regress_test_role2; -- ERROR
ERROR: permission denied for foreign-data wrapper foo
RESET ROLE;
ALTER SERVER s8 OPTIONS (foo '1'); -- ERROR option validation
2009-02-24 11:06:36 +01:00
ERROR: invalid option "foo"
2009-12-23 13:23:59 +01:00
HINT: Valid options in this context are: authtype, service, connect_timeout, dbname, host, hostaddr, port, tty, options, requiressl, sslmode, gsslib
2008-12-19 17:25:19 +01:00
ALTER SERVER s8 OPTIONS (connect_timeout '30', SET dbname 'db1', DROP host);
SET ROLE regress_test_role;
ALTER SERVER s1 OWNER TO regress_test_indirect; -- ERROR
ERROR: must be member of role "regress_test_indirect"
RESET ROLE;
GRANT regress_test_indirect TO regress_test_role;
SET ROLE regress_test_role;
ALTER SERVER s1 OWNER TO regress_test_indirect;
RESET ROLE;
GRANT USAGE ON FOREIGN DATA WRAPPER foo TO regress_test_indirect;
SET ROLE regress_test_role;
ALTER SERVER s1 OWNER TO regress_test_indirect;
RESET ROLE;
DROP ROLE regress_test_indirect; -- ERROR
ERROR: role "regress_test_indirect" cannot be dropped because some objects depend on it
DETAIL: owner of server s1
2010-08-26 21:49:08 +02:00
privileges for foreign-data wrapper foo
2008-12-19 17:25:19 +01:00
\des+
2016-07-18 00:42:31 +02:00
List of foreign servers
Name | Owner | Foreign-data wrapper | Access privileges | Type | Version | FDW Options | Description
------+---------------------------+----------------------+-------------------------------------------------------+--------+---------+--------------------------------------+-------------
s1 | regress_test_indirect | foo | regress_test_indirect=U/regress_test_indirect | | 1.1 | (servername 's1') |
s2 | regress_foreign_data_user | foo | | | 1.1 | (host 'a', dbname 'b') |
s3 | regress_foreign_data_user | foo | | oracle | | ("tns name" 'orcl', port '1521') |
s4 | regress_foreign_data_user | foo | | oracle | | (host 'a', dbname 'b') |
s5 | regress_foreign_data_user | foo | | | 15.0 | |
s6 | regress_foreign_data_user | foo | regress_foreign_data_user=U/regress_foreign_data_user+| | 16.0 | (host 'a', dbname 'b') |
| | | regress_test_role2=U*/regress_foreign_data_user | | | |
s7 | regress_foreign_data_user | foo | | oracle | 17.0 | (host 'a', dbname 'b') |
s8 | regress_foreign_data_user | postgresql | | | | (dbname 'db1', connect_timeout '30') |
t1 | regress_test_role | foo | | | | |
t2 | regress_test_role | foo | | | | |
2009-01-09 15:50:00 +01:00
(10 rows)
2008-12-19 17:25:19 +01:00
2011-12-09 19:42:30 +01:00
ALTER SERVER s8 RENAME to s8new;
\des+
2016-07-18 00:42:31 +02:00
List of foreign servers
Name | Owner | Foreign-data wrapper | Access privileges | Type | Version | FDW Options | Description
-------+---------------------------+----------------------+-------------------------------------------------------+--------+---------+--------------------------------------+-------------
s1 | regress_test_indirect | foo | regress_test_indirect=U/regress_test_indirect | | 1.1 | (servername 's1') |
s2 | regress_foreign_data_user | foo | | | 1.1 | (host 'a', dbname 'b') |
s3 | regress_foreign_data_user | foo | | oracle | | ("tns name" 'orcl', port '1521') |
s4 | regress_foreign_data_user | foo | | oracle | | (host 'a', dbname 'b') |
s5 | regress_foreign_data_user | foo | | | 15.0 | |
s6 | regress_foreign_data_user | foo | regress_foreign_data_user=U/regress_foreign_data_user+| | 16.0 | (host 'a', dbname 'b') |
| | | regress_test_role2=U*/regress_foreign_data_user | | | |
s7 | regress_foreign_data_user | foo | | oracle | 17.0 | (host 'a', dbname 'b') |
s8new | regress_foreign_data_user | postgresql | | | | (dbname 'db1', connect_timeout '30') |
t1 | regress_test_role | foo | | | | |
t2 | regress_test_role | foo | | | | |
2011-12-09 19:42:30 +01:00
(10 rows)
ALTER SERVER s8new RENAME to s8;
2008-12-19 17:25:19 +01:00
-- DROP SERVER
DROP SERVER nonexistent; -- ERROR
ERROR: server "nonexistent" does not exist
DROP SERVER IF EXISTS nonexistent;
NOTICE: server "nonexistent" does not exist, skipping
\des
2016-07-18 00:42:31 +02:00
List of foreign servers
Name | Owner | Foreign-data wrapper
------+---------------------------+----------------------
s1 | regress_test_indirect | foo
s2 | regress_foreign_data_user | foo
s3 | regress_foreign_data_user | foo
s4 | regress_foreign_data_user | foo
s5 | regress_foreign_data_user | foo
s6 | regress_foreign_data_user | foo
s7 | regress_foreign_data_user | foo
s8 | regress_foreign_data_user | postgresql
t1 | regress_test_role | foo
t2 | regress_test_role | foo
2009-01-09 15:50:00 +01:00
(10 rows)
2008-12-19 17:25:19 +01:00
SET ROLE regress_test_role;
DROP SERVER s2; -- ERROR
ERROR: must be owner of foreign server s2
DROP SERVER s1;
RESET ROLE;
\des
2016-07-18 00:42:31 +02:00
List of foreign servers
Name | Owner | Foreign-data wrapper
------+---------------------------+----------------------
s2 | regress_foreign_data_user | foo
s3 | regress_foreign_data_user | foo
s4 | regress_foreign_data_user | foo
s5 | regress_foreign_data_user | foo
s6 | regress_foreign_data_user | foo
s7 | regress_foreign_data_user | foo
s8 | regress_foreign_data_user | postgresql
t1 | regress_test_role | foo
t2 | regress_test_role | foo
2009-01-09 15:50:00 +01:00
(9 rows)
2008-12-19 17:25:19 +01:00
ALTER SERVER s2 OWNER TO regress_test_role;
SET ROLE regress_test_role;
DROP SERVER s2;
RESET ROLE;
\des
2016-07-18 00:42:31 +02:00
List of foreign servers
Name | Owner | Foreign-data wrapper
------+---------------------------+----------------------
s3 | regress_foreign_data_user | foo
s4 | regress_foreign_data_user | foo
s5 | regress_foreign_data_user | foo
s6 | regress_foreign_data_user | foo
s7 | regress_foreign_data_user | foo
s8 | regress_foreign_data_user | postgresql
t1 | regress_test_role | foo
t2 | regress_test_role | foo
2009-01-09 15:50:00 +01:00
(8 rows)
2008-12-19 17:25:19 +01:00
CREATE USER MAPPING FOR current_user SERVER s3;
\deu
2016-07-18 00:42:31 +02:00
List of user mappings
Server | User name
--------+---------------------------
s3 | regress_foreign_data_user
2008-12-19 17:25:19 +01:00
(1 row)
DROP SERVER s3; -- ERROR
ERROR: cannot drop server s3 because other objects depend on it
2016-07-18 00:42:31 +02:00
DETAIL: user mapping for regress_foreign_data_user on server s3 depends on server s3
2008-12-19 17:25:19 +01:00
HINT: Use DROP ... CASCADE to drop the dependent objects too.
DROP SERVER s3 CASCADE;
2016-07-18 00:42:31 +02:00
NOTICE: drop cascades to user mapping for regress_foreign_data_user on server s3
2008-12-19 17:25:19 +01:00
\des
2016-07-18 00:42:31 +02:00
List of foreign servers
Name | Owner | Foreign-data wrapper
------+---------------------------+----------------------
s4 | regress_foreign_data_user | foo
s5 | regress_foreign_data_user | foo
s6 | regress_foreign_data_user | foo
s7 | regress_foreign_data_user | foo
s8 | regress_foreign_data_user | postgresql
t1 | regress_test_role | foo
t2 | regress_test_role | foo
2009-01-09 15:50:00 +01:00
(7 rows)
2008-12-19 17:25:19 +01:00
\deu
List of user mappings
2009-03-25 14:11:43 +01:00
Server | User name
--------+-----------
2008-12-19 17:25:19 +01:00
(0 rows)
-- CREATE USER MAPPING
2009-10-15 01:36:43 +02:00
CREATE USER MAPPING FOR regress_test_missing_role SERVER s1; -- ERROR
ERROR: role "regress_test_missing_role" does not exist
2008-12-19 17:25:19 +01:00
CREATE USER MAPPING FOR current_user SERVER s1; -- ERROR
ERROR: server "s1" does not exist
CREATE USER MAPPING FOR current_user SERVER s4;
CREATE USER MAPPING FOR user SERVER s4; -- ERROR duplicate
2016-07-18 00:42:31 +02:00
ERROR: user mapping "regress_foreign_data_user" already exists for server s4
2011-08-25 18:47:30 +02:00
CREATE USER MAPPING FOR public SERVER s4 OPTIONS ("this mapping" 'is public');
2008-12-19 17:25:19 +01:00
CREATE USER MAPPING FOR user SERVER s8 OPTIONS (username 'test', password 'secret'); -- ERROR
2009-02-24 11:06:36 +01:00
ERROR: invalid option "username"
2009-12-23 13:23:59 +01:00
HINT: Valid options in this context are: user, password
2008-12-19 17:25:19 +01:00
CREATE USER MAPPING FOR user SERVER s8 OPTIONS (user 'test', password 'secret');
ALTER SERVER s5 OWNER TO regress_test_role;
ALTER SERVER s6 OWNER TO regress_test_indirect;
SET ROLE regress_test_role;
CREATE USER MAPPING FOR current_user SERVER s5;
CREATE USER MAPPING FOR current_user SERVER s6 OPTIONS (username 'test');
CREATE USER MAPPING FOR current_user SERVER s7; -- ERROR
2009-01-20 10:10:20 +01:00
ERROR: permission denied for foreign server s7
2008-12-19 17:25:19 +01:00
CREATE USER MAPPING FOR public SERVER s8; -- ERROR
ERROR: must be owner of foreign server s8
RESET ROLE;
2009-03-09 16:04:21 +01:00
ALTER SERVER t1 OWNER TO regress_test_indirect;
2008-12-19 17:25:19 +01:00
SET ROLE regress_test_role;
2009-03-09 16:04:21 +01:00
CREATE USER MAPPING FOR current_user SERVER t1 OPTIONS (username 'bob', password 'boo');
CREATE USER MAPPING FOR public SERVER t1;
2008-12-19 17:25:19 +01:00
RESET ROLE;
\deu
2016-07-18 00:42:31 +02:00
List of user mappings
Server | User name
--------+---------------------------
2008-12-19 17:25:19 +01:00
s4 | public
2016-07-18 00:42:31 +02:00
s4 | regress_foreign_data_user
2008-12-19 17:25:19 +01:00
s5 | regress_test_role
s6 | regress_test_role
2016-07-18 00:42:31 +02:00
s8 | regress_foreign_data_user
2009-03-09 16:04:21 +01:00
t1 | public
t1 | regress_test_role
2009-01-09 15:50:00 +01:00
(7 rows)
2008-12-19 17:25:19 +01:00
-- ALTER USER MAPPING
2009-10-15 01:36:43 +02:00
ALTER USER MAPPING FOR regress_test_missing_role SERVER s4 OPTIONS (gotcha 'true'); -- ERROR
ERROR: role "regress_test_missing_role" does not exist
2008-12-19 17:25:19 +01:00
ALTER USER MAPPING FOR user SERVER ss4 OPTIONS (gotcha 'true'); -- ERROR
ERROR: server "ss4" does not exist
ALTER USER MAPPING FOR public SERVER s5 OPTIONS (gotcha 'true'); -- ERROR
ERROR: user mapping "public" does not exist for the server
ALTER USER MAPPING FOR current_user SERVER s8 OPTIONS (username 'test'); -- ERROR
2009-02-24 11:06:36 +01:00
ERROR: invalid option "username"
2009-12-23 13:23:59 +01:00
HINT: Valid options in this context are: user, password
2008-12-19 17:25:19 +01:00
ALTER USER MAPPING FOR current_user SERVER s8 OPTIONS (DROP user, SET password 'public');
SET ROLE regress_test_role;
ALTER USER MAPPING FOR current_user SERVER s5 OPTIONS (ADD modified '1');
ALTER USER MAPPING FOR public SERVER s4 OPTIONS (ADD modified '1'); -- ERROR
ERROR: must be owner of foreign server s4
2009-03-09 16:04:21 +01:00
ALTER USER MAPPING FOR public SERVER t1 OPTIONS (ADD modified '1');
2008-12-19 17:25:19 +01:00
RESET ROLE;
\deu+
2016-07-18 00:42:31 +02:00
List of user mappings
Server | User name | FDW Options
--------+---------------------------+----------------------------------
s4 | public | ("this mapping" 'is public')
s4 | regress_foreign_data_user |
s5 | regress_test_role | (modified '1')
s6 | regress_test_role | (username 'test')
s8 | regress_foreign_data_user | (password 'public')
t1 | public | (modified '1')
t1 | regress_test_role | (username 'bob', password 'boo')
2009-01-09 15:50:00 +01:00
(7 rows)
2008-12-19 17:25:19 +01:00
-- DROP USER MAPPING
2009-10-15 01:36:43 +02:00
DROP USER MAPPING FOR regress_test_missing_role SERVER s4; -- ERROR
ERROR: role "regress_test_missing_role" does not exist
2008-12-19 17:25:19 +01:00
DROP USER MAPPING FOR user SERVER ss4;
ERROR: server "ss4" does not exist
DROP USER MAPPING FOR public SERVER s7; -- ERROR
ERROR: user mapping "public" does not exist for the server
2009-10-15 01:36:43 +02:00
DROP USER MAPPING IF EXISTS FOR regress_test_missing_role SERVER s4;
NOTICE: role "regress_test_missing_role" does not exist, skipping
2008-12-19 17:25:19 +01:00
DROP USER MAPPING IF EXISTS FOR user SERVER ss4;
NOTICE: server does not exist, skipping
DROP USER MAPPING IF EXISTS FOR public SERVER s7;
NOTICE: user mapping "public" does not exist for the server, skipping
CREATE USER MAPPING FOR public SERVER s8;
SET ROLE regress_test_role;
DROP USER MAPPING FOR public SERVER s8; -- ERROR
ERROR: must be owner of foreign server s8
RESET ROLE;
DROP SERVER s7;
\deu
2016-07-18 00:42:31 +02:00
List of user mappings
Server | User name
--------+---------------------------
2008-12-19 17:25:19 +01:00
s4 | public
2016-07-18 00:42:31 +02:00
s4 | regress_foreign_data_user
2008-12-19 17:25:19 +01:00
s5 | regress_test_role
s6 | regress_test_role
s8 | public
2016-07-18 00:42:31 +02:00
s8 | regress_foreign_data_user
2009-03-09 16:04:21 +01:00
t1 | public
t1 | regress_test_role
2009-01-09 15:50:00 +01:00
(8 rows)
2008-12-19 17:25:19 +01:00
2011-01-02 05:48:11 +01:00
-- CREATE FOREIGN TABLE
CREATE SCHEMA foreign_schema;
2011-10-10 13:58:17 +02:00
CREATE SERVER s0 FOREIGN DATA WRAPPER dummy;
2011-01-02 05:48:11 +01:00
CREATE FOREIGN TABLE ft1 (); -- ERROR
ERROR: syntax error at or near ";"
LINE 1: CREATE FOREIGN TABLE ft1 ();
^
CREATE FOREIGN TABLE ft1 () SERVER no_server; -- ERROR
ERROR: server "no_server" does not exist
2011-10-10 13:58:17 +02:00
CREATE FOREIGN TABLE ft1 () SERVER s0 WITH OIDS; -- ERROR
Improve parser's one-extra-token lookahead mechanism.
There are a couple of places in our grammar that fail to be strict LALR(1),
by requiring more than a single token of lookahead to decide what to do.
Up to now we've dealt with that by using a filter between the lexer and
parser that merges adjacent tokens into one in the places where two tokens
of lookahead are necessary. But that creates a number of user-visible
anomalies, for instance that you can't name a CTE "ordinality" because
"WITH ordinality AS ..." triggers folding of WITH and ORDINALITY into one
token. I realized that there's a better way.
In this patch, we still do the lookahead basically as before, but we never
merge the second token into the first; we replace just the first token by
a special lookahead symbol when one of the lookahead pairs is seen.
This requires a couple extra productions in the grammar, but it involves
fewer special tokens, so that the grammar tables come out a bit smaller
than before. The filter logic is no slower than before, perhaps a bit
faster.
I also fixed the filter logic so that when backing up after a lookahead,
the current token's terminator is correctly restored; this eliminates some
weird behavior in error message issuance, as is shown by the one change in
existing regression test outputs.
I believe that this patch entirely eliminates odd behaviors caused by
lookahead for WITH. It doesn't really improve the situation for NULLS
followed by FIRST/LAST unfortunately: those sequences still act like a
reserved word, even though there are cases where they should be seen as two
ordinary identifiers, eg "SELECT nulls first FROM ...". I experimented
with additional grammar hacks but couldn't find any simple solution for
that. Still, this is better than before, and it seems much more likely
that we *could* somehow solve the NULLS case on the basis of this filter
behavior than the previous one.
2015-02-24 23:53:42 +01:00
ERROR: syntax error at or near "WITH"
2011-10-10 13:58:17 +02:00
LINE 1: CREATE FOREIGN TABLE ft1 () SERVER s0 WITH OIDS;
2011-01-02 05:48:11 +01:00
^
CREATE FOREIGN TABLE ft1 (
2014-12-17 23:00:53 +01:00
c1 integer OPTIONS ("param 1" 'val1') PRIMARY KEY,
c2 text OPTIONS (param2 'val2', param3 'val3'),
c3 date
) SERVER s0 OPTIONS (delimiter ',', quote '"', "be quoted" 'value'); -- ERROR
ERROR: primary key constraints are not supported on foreign tables
LINE 2: c1 integer OPTIONS ("param 1" 'val1') PRIMARY KEY,
^
CREATE TABLE ref_table (id integer PRIMARY KEY);
CREATE FOREIGN TABLE ft1 (
c1 integer OPTIONS ("param 1" 'val1') REFERENCES ref_table (id),
2011-08-05 19:24:03 +02:00
c2 text OPTIONS (param2 'val2', param3 'val3'),
2011-01-02 05:48:11 +01:00
c3 date
2014-12-17 23:00:53 +01:00
) SERVER s0 OPTIONS (delimiter ',', quote '"', "be quoted" 'value'); -- ERROR
ERROR: foreign key constraints are not supported on foreign tables
LINE 2: c1 integer OPTIONS ("param 1" 'val1') REFERENCES ref_table ...
^
DROP TABLE ref_table;
CREATE FOREIGN TABLE ft1 (
c1 integer OPTIONS ("param 1" 'val1') NOT NULL,
c2 text OPTIONS (param2 'val2', param3 'val3'),
c3 date,
UNIQUE (c3)
) SERVER s0 OPTIONS (delimiter ',', quote '"', "be quoted" 'value'); -- ERROR
ERROR: unique constraints are not supported on foreign tables
LINE 5: UNIQUE (c3)
^
CREATE FOREIGN TABLE ft1 (
c1 integer OPTIONS ("param 1" 'val1') NOT NULL,
c2 text OPTIONS (param2 'val2', param3 'val3') CHECK (c2 <> ''),
c3 date,
CHECK (c3 BETWEEN '1994-01-01'::date AND '1994-01-31'::date)
2011-10-10 13:58:17 +02:00
) SERVER s0 OPTIONS (delimiter ',', quote '"', "be quoted" 'value');
2011-01-02 05:48:11 +01:00
COMMENT ON FOREIGN TABLE ft1 IS 'ft1';
COMMENT ON COLUMN ft1.c1 IS 'ft1.c1';
\d+ ft1
2016-11-03 17:00:00 +01:00
Foreign table "public.ft1"
Column | Type | Collation | Nullable | Default | FDW Options | Storage | Stats target | Description
--------+---------+-----------+----------+---------+--------------------------------+----------+--------------+-------------
c1 | integer | | not null | | ("param 1" 'val1') | plain | | ft1.c1
c2 | text | | | | (param2 'val2', param3 'val3') | extended | |
c3 | date | | | | | plain | |
2014-12-17 23:00:53 +01:00
Check constraints:
"ft1_c2_check" CHECK (c2 <> ''::text)
"ft1_c3_check" CHECK (c3 >= '01-01-1994'::date AND c3 <= '01-31-1994'::date)
2011-10-10 13:58:17 +02:00
Server: s0
2011-08-25 18:47:30 +02:00
FDW Options: (delimiter ',', quote '"', "be quoted" 'value')
2011-01-02 05:48:11 +01:00
\det+
2011-08-25 18:47:30 +02:00
List of foreign tables
Schema | Table | Server | FDW Options | Description
--------+-------+--------+-------------------------------------------------+-------------
2011-10-10 13:58:17 +02:00
public | ft1 | s0 | (delimiter ',', quote '"', "be quoted" 'value') | ft1
2011-01-02 05:48:11 +01:00
(1 row)
CREATE INDEX id_ft1_c2 ON ft1 (c2); -- ERROR
2011-05-05 23:00:31 +02:00
ERROR: cannot create index on foreign table "ft1"
2011-02-19 06:06:18 +01:00
SELECT * FROM ft1; -- ERROR
2011-02-20 06:17:18 +01:00
ERROR: foreign-data wrapper "dummy" has no handler
2011-02-19 06:06:18 +01:00
EXPLAIN SELECT * FROM ft1; -- ERROR
2011-02-20 06:17:18 +01:00
ERROR: foreign-data wrapper "dummy" has no handler
2011-01-02 05:48:11 +01:00
-- ALTER FOREIGN TABLE
COMMENT ON FOREIGN TABLE ft1 IS 'foreign table';
COMMENT ON FOREIGN TABLE ft1 IS NULL;
COMMENT ON COLUMN ft1.c1 IS 'foreign column';
COMMENT ON COLUMN ft1.c1 IS NULL;
ALTER FOREIGN TABLE ft1 ADD COLUMN c4 integer;
2013-03-12 22:37:07 +01:00
ALTER FOREIGN TABLE ft1 ADD COLUMN c5 integer DEFAULT 0;
2011-01-02 05:48:11 +01:00
ALTER FOREIGN TABLE ft1 ADD COLUMN c6 integer;
ALTER FOREIGN TABLE ft1 ADD COLUMN c7 integer NOT NULL;
ALTER FOREIGN TABLE ft1 ADD COLUMN c8 integer;
ALTER FOREIGN TABLE ft1 ADD COLUMN c9 integer;
2011-08-05 19:24:03 +02:00
ALTER FOREIGN TABLE ft1 ADD COLUMN c10 integer OPTIONS (p1 'v1');
2013-03-12 22:37:07 +01:00
ALTER FOREIGN TABLE ft1 ALTER COLUMN c4 SET DEFAULT 0;
ALTER FOREIGN TABLE ft1 ALTER COLUMN c5 DROP DEFAULT;
2011-01-02 05:48:11 +01:00
ALTER FOREIGN TABLE ft1 ALTER COLUMN c6 SET NOT NULL;
ALTER FOREIGN TABLE ft1 ALTER COLUMN c7 DROP NOT NULL;
2011-07-04 23:01:35 +02:00
ALTER FOREIGN TABLE ft1 ALTER COLUMN c8 TYPE char(10) USING '0'; -- ERROR
ERROR: "ft1" is not a table
2011-01-02 05:48:11 +01:00
ALTER FOREIGN TABLE ft1 ALTER COLUMN c8 TYPE char(10);
ALTER FOREIGN TABLE ft1 ALTER COLUMN c8 SET DATA TYPE text;
2011-08-05 19:24:03 +02:00
ALTER FOREIGN TABLE ft1 ALTER COLUMN xmin OPTIONS (ADD p1 'v1'); -- ERROR
ERROR: cannot alter system column "xmin"
ALTER FOREIGN TABLE ft1 ALTER COLUMN c7 OPTIONS (ADD p1 'v1', ADD p2 'v2'),
ALTER COLUMN c8 OPTIONS (ADD p1 'v1', ADD p2 'v2');
ALTER FOREIGN TABLE ft1 ALTER COLUMN c8 OPTIONS (SET p2 'V2', DROP p1);
2012-04-06 21:02:35 +02:00
ALTER FOREIGN TABLE ft1 ALTER COLUMN c1 SET STATISTICS 10000;
ALTER FOREIGN TABLE ft1 ALTER COLUMN c1 SET (n_distinct = 100);
ALTER FOREIGN TABLE ft1 ALTER COLUMN c8 SET STATISTICS -1;
Allow foreign tables to participate in inheritance.
Foreign tables can now be inheritance children, or parents. Much of the
system was already ready for this, but we had to fix a few things of
course, mostly in the area of planner and executor handling of row locks.
As side effects of this, allow foreign tables to have NOT VALID CHECK
constraints (and hence to accept ALTER ... VALIDATE CONSTRAINT), and to
accept ALTER SET STORAGE and ALTER SET WITH/WITHOUT OIDS. Continuing to
disallow these things would've required bizarre and inconsistent special
cases in inheritance behavior. Since foreign tables don't enforce CHECK
constraints anyway, a NOT VALID one is a complete no-op, but that doesn't
mean we shouldn't allow it. And it's possible that some FDWs might have
use for SET STORAGE or SET WITH OIDS, though doubtless they will be no-ops
for most.
An additional change in support of this is that when a ModifyTable node
has multiple target tables, they will all now be explicitly identified
in EXPLAIN output, for example:
Update on pt1 (cost=0.00..321.05 rows=3541 width=46)
Update on pt1
Foreign Update on ft1
Foreign Update on ft2
Update on child3
-> Seq Scan on pt1 (cost=0.00..0.00 rows=1 width=46)
-> Foreign Scan on ft1 (cost=100.00..148.03 rows=1170 width=46)
-> Foreign Scan on ft2 (cost=100.00..148.03 rows=1170 width=46)
-> Seq Scan on child3 (cost=0.00..25.00 rows=1200 width=46)
This was done mainly to provide an unambiguous place to attach "Remote SQL"
fields, but it is useful for inherited updates even when no foreign tables
are involved.
Shigeru Hanada and Etsuro Fujita, reviewed by Ashutosh Bapat and Kyotaro
Horiguchi, some additional hacking by me
2015-03-22 18:53:11 +01:00
ALTER FOREIGN TABLE ft1 ALTER COLUMN c8 SET STORAGE PLAIN;
2011-08-05 19:24:03 +02:00
\d+ ft1
2016-11-03 17:00:00 +01:00
Foreign table "public.ft1"
Column | Type | Collation | Nullable | Default | FDW Options | Storage | Stats target | Description
--------+---------+-----------+----------+---------+--------------------------------+----------+--------------+-------------
c1 | integer | | not null | | ("param 1" 'val1') | plain | 10000 |
c2 | text | | | | (param2 'val2', param3 'val3') | extended | |
c3 | date | | | | | plain | |
c4 | integer | | | 0 | | plain | |
c5 | integer | | | | | plain | |
c6 | integer | | not null | | | plain | |
c7 | integer | | | | (p1 'v1', p2 'v2') | plain | |
c8 | text | | | | (p2 'V2') | plain | |
c9 | integer | | | | | plain | |
c10 | integer | | | | (p1 'v1') | plain | |
2014-12-17 23:00:53 +01:00
Check constraints:
"ft1_c2_check" CHECK (c2 <> ''::text)
"ft1_c3_check" CHECK (c3 >= '01-01-1994'::date AND c3 <= '01-31-1994'::date)
2011-10-10 13:58:17 +02:00
Server: s0
2011-08-25 18:47:30 +02:00
FDW Options: (delimiter ',', quote '"', "be quoted" 'value')
2011-08-05 19:24:03 +02:00
2011-02-06 06:26:27 +01:00
-- can't change the column type if it's used elsewhere
CREATE TABLE use_ft1_column_type (x ft1);
ALTER FOREIGN TABLE ft1 ALTER COLUMN c8 SET DATA TYPE integer; -- ERROR
2011-06-21 23:33:20 +02:00
ERROR: cannot alter foreign table "ft1" because column "use_ft1_column_type.x" uses its row type
2011-02-06 06:26:27 +01:00
DROP TABLE use_ft1_column_type;
2014-12-17 23:00:53 +01:00
ALTER FOREIGN TABLE ft1 ADD PRIMARY KEY (c7); -- ERROR
ERROR: primary key constraints are not supported on foreign tables
LINE 1: ALTER FOREIGN TABLE ft1 ADD PRIMARY KEY (c7);
2013-03-12 22:37:07 +01:00
^
Allow foreign tables to participate in inheritance.
Foreign tables can now be inheritance children, or parents. Much of the
system was already ready for this, but we had to fix a few things of
course, mostly in the area of planner and executor handling of row locks.
As side effects of this, allow foreign tables to have NOT VALID CHECK
constraints (and hence to accept ALTER ... VALIDATE CONSTRAINT), and to
accept ALTER SET STORAGE and ALTER SET WITH/WITHOUT OIDS. Continuing to
disallow these things would've required bizarre and inconsistent special
cases in inheritance behavior. Since foreign tables don't enforce CHECK
constraints anyway, a NOT VALID one is a complete no-op, but that doesn't
mean we shouldn't allow it. And it's possible that some FDWs might have
use for SET STORAGE or SET WITH OIDS, though doubtless they will be no-ops
for most.
An additional change in support of this is that when a ModifyTable node
has multiple target tables, they will all now be explicitly identified
in EXPLAIN output, for example:
Update on pt1 (cost=0.00..321.05 rows=3541 width=46)
Update on pt1
Foreign Update on ft1
Foreign Update on ft2
Update on child3
-> Seq Scan on pt1 (cost=0.00..0.00 rows=1 width=46)
-> Foreign Scan on ft1 (cost=100.00..148.03 rows=1170 width=46)
-> Foreign Scan on ft2 (cost=100.00..148.03 rows=1170 width=46)
-> Seq Scan on child3 (cost=0.00..25.00 rows=1200 width=46)
This was done mainly to provide an unambiguous place to attach "Remote SQL"
fields, but it is useful for inherited updates even when no foreign tables
are involved.
Shigeru Hanada and Etsuro Fujita, reviewed by Ashutosh Bapat and Kyotaro
Horiguchi, some additional hacking by me
2015-03-22 18:53:11 +01:00
ALTER FOREIGN TABLE ft1 ADD CONSTRAINT ft1_c9_check CHECK (c9 < 0) NOT VALID;
2014-12-17 23:00:53 +01:00
ALTER FOREIGN TABLE ft1 ALTER CONSTRAINT ft1_c9_check DEFERRABLE; -- ERROR
2011-01-02 05:48:11 +01:00
ERROR: "ft1" is not a table
2014-12-17 23:00:53 +01:00
ALTER FOREIGN TABLE ft1 DROP CONSTRAINT ft1_c9_check;
ALTER FOREIGN TABLE ft1 DROP CONSTRAINT no_const; -- ERROR
ERROR: constraint "no_const" of relation "ft1" does not exist
2011-01-02 05:48:11 +01:00
ALTER FOREIGN TABLE ft1 DROP CONSTRAINT IF EXISTS no_const;
2014-12-17 23:00:53 +01:00
NOTICE: constraint "no_const" of relation "ft1" does not exist, skipping
Allow foreign tables to participate in inheritance.
Foreign tables can now be inheritance children, or parents. Much of the
system was already ready for this, but we had to fix a few things of
course, mostly in the area of planner and executor handling of row locks.
As side effects of this, allow foreign tables to have NOT VALID CHECK
constraints (and hence to accept ALTER ... VALIDATE CONSTRAINT), and to
accept ALTER SET STORAGE and ALTER SET WITH/WITHOUT OIDS. Continuing to
disallow these things would've required bizarre and inconsistent special
cases in inheritance behavior. Since foreign tables don't enforce CHECK
constraints anyway, a NOT VALID one is a complete no-op, but that doesn't
mean we shouldn't allow it. And it's possible that some FDWs might have
use for SET STORAGE or SET WITH OIDS, though doubtless they will be no-ops
for most.
An additional change in support of this is that when a ModifyTable node
has multiple target tables, they will all now be explicitly identified
in EXPLAIN output, for example:
Update on pt1 (cost=0.00..321.05 rows=3541 width=46)
Update on pt1
Foreign Update on ft1
Foreign Update on ft2
Update on child3
-> Seq Scan on pt1 (cost=0.00..0.00 rows=1 width=46)
-> Foreign Scan on ft1 (cost=100.00..148.03 rows=1170 width=46)
-> Foreign Scan on ft2 (cost=100.00..148.03 rows=1170 width=46)
-> Seq Scan on child3 (cost=0.00..25.00 rows=1200 width=46)
This was done mainly to provide an unambiguous place to attach "Remote SQL"
fields, but it is useful for inherited updates even when no foreign tables
are involved.
Shigeru Hanada and Etsuro Fujita, reviewed by Ashutosh Bapat and Kyotaro
Horiguchi, some additional hacking by me
2015-03-22 18:53:11 +01:00
ALTER FOREIGN TABLE ft1 SET WITH OIDS;
2011-01-02 05:48:11 +01:00
ALTER FOREIGN TABLE ft1 OWNER TO regress_test_role;
ALTER FOREIGN TABLE ft1 OPTIONS (DROP delimiter, SET quote '~', ADD escape '@');
ALTER FOREIGN TABLE ft1 DROP COLUMN no_column; -- ERROR
ERROR: column "no_column" of relation "ft1" does not exist
ALTER FOREIGN TABLE ft1 DROP COLUMN IF EXISTS no_column;
NOTICE: column "no_column" of relation "ft1" does not exist, skipping
ALTER FOREIGN TABLE ft1 DROP COLUMN c9;
ALTER FOREIGN TABLE ft1 SET SCHEMA foreign_schema;
ALTER FOREIGN TABLE ft1 SET TABLESPACE ts; -- ERROR
ERROR: relation "ft1" does not exist
ALTER FOREIGN TABLE foreign_schema.ft1 RENAME c1 TO foreign_column_1;
ALTER FOREIGN TABLE foreign_schema.ft1 RENAME TO foreign_table_1;
\d foreign_schema.foreign_table_1
2016-11-03 17:00:00 +01:00
Foreign table "foreign_schema.foreign_table_1"
Column | Type | Collation | Nullable | Default | FDW Options
------------------+---------+-----------+----------+---------+--------------------------------
foreign_column_1 | integer | | not null | | ("param 1" 'val1')
c2 | text | | | | (param2 'val2', param3 'val3')
c3 | date | | | |
c4 | integer | | | 0 |
c5 | integer | | | |
c6 | integer | | not null | |
c7 | integer | | | | (p1 'v1', p2 'v2')
c8 | text | | | | (p2 'V2')
c10 | integer | | | | (p1 'v1')
2014-12-17 23:00:53 +01:00
Check constraints:
"ft1_c2_check" CHECK (c2 <> ''::text)
"ft1_c3_check" CHECK (c3 >= '01-01-1994'::date AND c3 <= '01-31-1994'::date)
2011-10-10 13:58:17 +02:00
Server: s0
2011-08-25 18:47:30 +02:00
FDW Options: (quote '~', "be quoted" 'value', escape '@')
2011-01-02 05:48:11 +01:00
2012-01-24 00:25:04 +01:00
-- alter noexisting table
ALTER FOREIGN TABLE IF EXISTS doesnt_exist_ft1 ADD COLUMN c4 integer;
NOTICE: relation "doesnt_exist_ft1" does not exist, skipping
ALTER FOREIGN TABLE IF EXISTS doesnt_exist_ft1 ADD COLUMN c6 integer;
NOTICE: relation "doesnt_exist_ft1" does not exist, skipping
ALTER FOREIGN TABLE IF EXISTS doesnt_exist_ft1 ADD COLUMN c7 integer NOT NULL;
NOTICE: relation "doesnt_exist_ft1" does not exist, skipping
ALTER FOREIGN TABLE IF EXISTS doesnt_exist_ft1 ADD COLUMN c8 integer;
NOTICE: relation "doesnt_exist_ft1" does not exist, skipping
ALTER FOREIGN TABLE IF EXISTS doesnt_exist_ft1 ADD COLUMN c9 integer;
NOTICE: relation "doesnt_exist_ft1" does not exist, skipping
ALTER FOREIGN TABLE IF EXISTS doesnt_exist_ft1 ADD COLUMN c10 integer OPTIONS (p1 'v1');
NOTICE: relation "doesnt_exist_ft1" does not exist, skipping
ALTER FOREIGN TABLE IF EXISTS doesnt_exist_ft1 ALTER COLUMN c6 SET NOT NULL;
NOTICE: relation "doesnt_exist_ft1" does not exist, skipping
ALTER FOREIGN TABLE IF EXISTS doesnt_exist_ft1 ALTER COLUMN c7 DROP NOT NULL;
NOTICE: relation "doesnt_exist_ft1" does not exist, skipping
ALTER FOREIGN TABLE IF EXISTS doesnt_exist_ft1 ALTER COLUMN c8 TYPE char(10);
NOTICE: relation "doesnt_exist_ft1" does not exist, skipping
ALTER FOREIGN TABLE IF EXISTS doesnt_exist_ft1 ALTER COLUMN c8 SET DATA TYPE text;
NOTICE: relation "doesnt_exist_ft1" does not exist, skipping
ALTER FOREIGN TABLE IF EXISTS doesnt_exist_ft1 ALTER COLUMN c7 OPTIONS (ADD p1 'v1', ADD p2 'v2'),
ALTER COLUMN c8 OPTIONS (ADD p1 'v1', ADD p2 'v2');
NOTICE: relation "doesnt_exist_ft1" does not exist, skipping
ALTER FOREIGN TABLE IF EXISTS doesnt_exist_ft1 ALTER COLUMN c8 OPTIONS (SET p2 'V2', DROP p1);
NOTICE: relation "doesnt_exist_ft1" does not exist, skipping
ALTER FOREIGN TABLE IF EXISTS doesnt_exist_ft1 DROP CONSTRAINT IF EXISTS no_const;
NOTICE: relation "doesnt_exist_ft1" does not exist, skipping
ALTER FOREIGN TABLE IF EXISTS doesnt_exist_ft1 DROP CONSTRAINT ft1_c1_check;
NOTICE: relation "doesnt_exist_ft1" does not exist, skipping
ALTER FOREIGN TABLE IF EXISTS doesnt_exist_ft1 OWNER TO regress_test_role;
NOTICE: relation "doesnt_exist_ft1" does not exist, skipping
ALTER FOREIGN TABLE IF EXISTS doesnt_exist_ft1 OPTIONS (DROP delimiter, SET quote '~', ADD escape '@');
NOTICE: relation "doesnt_exist_ft1" does not exist, skipping
ALTER FOREIGN TABLE IF EXISTS doesnt_exist_ft1 DROP COLUMN IF EXISTS no_column;
NOTICE: relation "doesnt_exist_ft1" does not exist, skipping
ALTER FOREIGN TABLE IF EXISTS doesnt_exist_ft1 DROP COLUMN c9;
NOTICE: relation "doesnt_exist_ft1" does not exist, skipping
ALTER FOREIGN TABLE IF EXISTS doesnt_exist_ft1 SET SCHEMA foreign_schema;
NOTICE: relation "doesnt_exist_ft1" does not exist, skipping
ALTER FOREIGN TABLE IF EXISTS doesnt_exist_ft1 RENAME c1 TO foreign_column_1;
NOTICE: relation "doesnt_exist_ft1" does not exist, skipping
ALTER FOREIGN TABLE IF EXISTS doesnt_exist_ft1 RENAME TO foreign_table_1;
NOTICE: relation "doesnt_exist_ft1" does not exist, skipping
2008-12-19 17:25:19 +01:00
-- Information schema
SELECT * FROM information_schema.foreign_data_wrappers ORDER BY 1, 2;
2016-07-18 00:42:31 +02:00
foreign_data_wrapper_catalog | foreign_data_wrapper_name | authorization_identifier | library_name | foreign_data_wrapper_language
------------------------------+---------------------------+---------------------------+--------------+-------------------------------
regression | dummy | regress_foreign_data_user | | c
regression | foo | regress_foreign_data_user | | c
regression | postgresql | regress_foreign_data_user | | c
2008-12-19 17:25:19 +01:00
(3 rows)
SELECT * FROM information_schema.foreign_data_wrapper_options ORDER BY 1, 2, 3;
foreign_data_wrapper_catalog | foreign_data_wrapper_name | option_name | option_value
------------------------------+---------------------------+--------------+--------------
2011-08-25 18:47:30 +02:00
regression | foo | test wrapper | true
2008-12-19 17:25:19 +01:00
(1 row)
SELECT * FROM information_schema.foreign_servers ORDER BY 1, 2;
2016-07-18 00:42:31 +02:00
foreign_server_catalog | foreign_server_name | foreign_data_wrapper_catalog | foreign_data_wrapper_name | foreign_server_type | foreign_server_version | authorization_identifier
------------------------+---------------------+------------------------------+---------------------------+---------------------+------------------------+---------------------------
regression | s0 | regression | dummy | | | regress_foreign_data_user
regression | s4 | regression | foo | oracle | | regress_foreign_data_user
2008-12-19 17:25:19 +01:00
regression | s5 | regression | foo | | 15.0 | regress_test_role
regression | s6 | regression | foo | | 16.0 | regress_test_indirect
2016-07-18 00:42:31 +02:00
regression | s8 | regression | postgresql | | | regress_foreign_data_user
2009-03-09 16:04:21 +01:00
regression | t1 | regression | foo | | | regress_test_indirect
regression | t2 | regression | foo | | | regress_test_role
2011-01-02 05:48:11 +01:00
(7 rows)
2008-12-19 17:25:19 +01:00
SELECT * FROM information_schema.foreign_server_options ORDER BY 1, 2, 3;
2009-01-09 15:50:00 +01:00
foreign_server_catalog | foreign_server_name | option_name | option_value
------------------------+---------------------+-----------------+--------------
regression | s4 | dbname | b
regression | s4 | host | a
regression | s6 | dbname | b
regression | s6 | host | a
regression | s8 | connect_timeout | 30
regression | s8 | dbname | db1
(6 rows)
2008-12-19 17:25:19 +01:00
2009-01-11 10:41:45 +01:00
SELECT * FROM information_schema.user_mappings ORDER BY lower(authorization_identifier), 2, 3;
2016-07-18 00:42:31 +02:00
authorization_identifier | foreign_server_catalog | foreign_server_name
---------------------------+------------------------+---------------------
PUBLIC | regression | s4
PUBLIC | regression | s8
PUBLIC | regression | t1
regress_foreign_data_user | regression | s4
regress_foreign_data_user | regression | s8
regress_test_role | regression | s5
regress_test_role | regression | s6
regress_test_role | regression | t1
2009-01-09 15:50:00 +01:00
(8 rows)
2008-12-19 17:25:19 +01:00
2009-01-11 10:41:45 +01:00
SELECT * FROM information_schema.user_mapping_options ORDER BY lower(authorization_identifier), 2, 3, 4;
2016-07-18 00:42:31 +02:00
authorization_identifier | foreign_server_catalog | foreign_server_name | option_name | option_value
---------------------------+------------------------+---------------------+--------------+--------------
PUBLIC | regression | s4 | this mapping | is public
PUBLIC | regression | t1 | modified | 1
regress_foreign_data_user | regression | s8 | password | public
regress_test_role | regression | s5 | modified | 1
regress_test_role | regression | s6 | username | test
regress_test_role | regression | t1 | password | boo
regress_test_role | regression | t1 | username | bob
2009-01-09 15:50:00 +01:00
(7 rows)
2008-12-19 17:25:19 +01:00
2012-01-27 20:58:51 +01:00
SELECT * FROM information_schema.usage_privileges WHERE object_type LIKE 'FOREIGN%' AND object_name IN ('s6', 'foo') ORDER BY 1, 2, 3, 4, 5;
2016-07-18 00:42:31 +02:00
grantor | grantee | object_catalog | object_schema | object_name | object_type | privilege_type | is_grantable
---------------------------+---------------------------+----------------+---------------+-------------+----------------------+----------------+--------------
regress_foreign_data_user | regress_foreign_data_user | regression | | foo | FOREIGN DATA WRAPPER | USAGE | YES
regress_foreign_data_user | regress_test_indirect | regression | | foo | FOREIGN DATA WRAPPER | USAGE | NO
regress_test_indirect | regress_test_indirect | regression | | s6 | FOREIGN SERVER | USAGE | YES
regress_test_indirect | regress_test_role2 | regression | | s6 | FOREIGN SERVER | USAGE | YES
2008-12-19 17:25:19 +01:00
(4 rows)
2012-01-27 20:58:51 +01:00
SELECT * FROM information_schema.role_usage_grants WHERE object_type LIKE 'FOREIGN%' AND object_name IN ('s6', 'foo') ORDER BY 1, 2, 3, 4, 5;
2016-07-18 00:42:31 +02:00
grantor | grantee | object_catalog | object_schema | object_name | object_type | privilege_type | is_grantable
---------------------------+---------------------------+----------------+---------------+-------------+----------------------+----------------+--------------
regress_foreign_data_user | regress_foreign_data_user | regression | | foo | FOREIGN DATA WRAPPER | USAGE | YES
regress_foreign_data_user | regress_test_indirect | regression | | foo | FOREIGN DATA WRAPPER | USAGE | NO
regress_test_indirect | regress_test_indirect | regression | | s6 | FOREIGN SERVER | USAGE | YES
regress_test_indirect | regress_test_role2 | regression | | s6 | FOREIGN SERVER | USAGE | YES
2008-12-19 17:25:19 +01:00
(4 rows)
2011-01-02 05:48:11 +01:00
SELECT * FROM information_schema.foreign_tables ORDER BY 1, 2, 3;
foreign_table_catalog | foreign_table_schema | foreign_table_name | foreign_server_catalog | foreign_server_name
-----------------------+----------------------+--------------------+------------------------+---------------------
2011-10-10 13:58:17 +02:00
regression | foreign_schema | foreign_table_1 | regression | s0
2011-01-02 05:48:11 +01:00
(1 row)
SELECT * FROM information_schema.foreign_table_options ORDER BY 1, 2, 3, 4;
foreign_table_catalog | foreign_table_schema | foreign_table_name | option_name | option_value
-----------------------+----------------------+--------------------+-------------+--------------
2011-08-25 18:47:30 +02:00
regression | foreign_schema | foreign_table_1 | be quoted | value
2011-01-02 05:48:11 +01:00
regression | foreign_schema | foreign_table_1 | escape | @
regression | foreign_schema | foreign_table_1 | quote | ~
2011-08-25 18:47:30 +02:00
(3 rows)
2011-01-02 05:48:11 +01:00
2008-12-19 17:25:19 +01:00
SET ROLE regress_test_role;
SELECT * FROM information_schema.user_mapping_options ORDER BY 1, 2, 3, 4;
authorization_identifier | foreign_server_catalog | foreign_server_name | option_name | option_value
--------------------------+------------------------+---------------------+-------------+--------------
2009-03-09 16:04:21 +01:00
PUBLIC | regression | t1 | modified | 1
2008-12-19 17:25:19 +01:00
regress_test_role | regression | s5 | modified | 1
regress_test_role | regression | s6 | username | test
2009-03-09 16:04:21 +01:00
regress_test_role | regression | t1 | password | boo
regress_test_role | regression | t1 | username | bob
2008-12-19 17:25:19 +01:00
(5 rows)
2012-01-27 20:58:51 +01:00
SELECT * FROM information_schema.usage_privileges WHERE object_type LIKE 'FOREIGN%' AND object_name IN ('s6', 'foo') ORDER BY 1, 2, 3, 4, 5;
2016-07-18 00:42:31 +02:00
grantor | grantee | object_catalog | object_schema | object_name | object_type | privilege_type | is_grantable
---------------------------+-----------------------+----------------+---------------+-------------+----------------------+----------------+--------------
regress_foreign_data_user | regress_test_indirect | regression | | foo | FOREIGN DATA WRAPPER | USAGE | NO
regress_test_indirect | regress_test_indirect | regression | | s6 | FOREIGN SERVER | USAGE | YES
regress_test_indirect | regress_test_role2 | regression | | s6 | FOREIGN SERVER | USAGE | YES
2015-01-22 18:36:34 +01:00
(3 rows)
2008-12-19 17:25:19 +01:00
2012-01-27 20:58:51 +01:00
SELECT * FROM information_schema.role_usage_grants WHERE object_type LIKE 'FOREIGN%' AND object_name IN ('s6', 'foo') ORDER BY 1, 2, 3, 4, 5;
2016-07-18 00:42:31 +02:00
grantor | grantee | object_catalog | object_schema | object_name | object_type | privilege_type | is_grantable
---------------------------+-----------------------+----------------+---------------+-------------+----------------------+----------------+--------------
regress_foreign_data_user | regress_test_indirect | regression | | foo | FOREIGN DATA WRAPPER | USAGE | NO
regress_test_indirect | regress_test_indirect | regression | | s6 | FOREIGN SERVER | USAGE | YES
regress_test_indirect | regress_test_role2 | regression | | s6 | FOREIGN SERVER | USAGE | YES
2015-01-22 18:36:34 +01:00
(3 rows)
2008-12-19 17:25:19 +01:00
2009-03-09 16:04:21 +01:00
DROP USER MAPPING FOR current_user SERVER t1;
2009-01-20 10:10:20 +01:00
SET ROLE regress_test_role2;
SELECT * FROM information_schema.user_mapping_options ORDER BY 1, 2, 3, 4;
authorization_identifier | foreign_server_catalog | foreign_server_name | option_name | option_value
--------------------------+------------------------+---------------------+-------------+--------------
regress_test_role | regression | s6 | username |
(1 row)
2008-12-19 17:25:19 +01:00
RESET ROLE;
-- has_foreign_data_wrapper_privilege
SELECT has_foreign_data_wrapper_privilege('regress_test_role',
(SELECT oid FROM pg_foreign_data_wrapper WHERE fdwname='foo'), 'USAGE');
has_foreign_data_wrapper_privilege
------------------------------------
t
(1 row)
SELECT has_foreign_data_wrapper_privilege('regress_test_role', 'foo', 'USAGE');
has_foreign_data_wrapper_privilege
------------------------------------
t
(1 row)
SELECT has_foreign_data_wrapper_privilege(
(SELECT oid FROM pg_roles WHERE rolname='regress_test_role'),
(SELECT oid FROM pg_foreign_data_wrapper WHERE fdwname='foo'), 'USAGE');
has_foreign_data_wrapper_privilege
------------------------------------
t
(1 row)
SELECT has_foreign_data_wrapper_privilege(
(SELECT oid FROM pg_foreign_data_wrapper WHERE fdwname='foo'), 'USAGE');
has_foreign_data_wrapper_privilege
------------------------------------
t
(1 row)
SELECT has_foreign_data_wrapper_privilege(
(SELECT oid FROM pg_roles WHERE rolname='regress_test_role'), 'foo', 'USAGE');
has_foreign_data_wrapper_privilege
------------------------------------
t
(1 row)
SELECT has_foreign_data_wrapper_privilege('foo', 'USAGE');
has_foreign_data_wrapper_privilege
------------------------------------
t
(1 row)
GRANT USAGE ON FOREIGN DATA WRAPPER foo TO regress_test_role;
SELECT has_foreign_data_wrapper_privilege('regress_test_role', 'foo', 'USAGE');
has_foreign_data_wrapper_privilege
------------------------------------
t
(1 row)
-- has_server_privilege
SELECT has_server_privilege('regress_test_role',
(SELECT oid FROM pg_foreign_server WHERE srvname='s8'), 'USAGE');
has_server_privilege
----------------------
f
(1 row)
SELECT has_server_privilege('regress_test_role', 's8', 'USAGE');
has_server_privilege
----------------------
f
(1 row)
SELECT has_server_privilege(
(SELECT oid FROM pg_roles WHERE rolname='regress_test_role'),
(SELECT oid FROM pg_foreign_server WHERE srvname='s8'), 'USAGE');
has_server_privilege
----------------------
f
(1 row)
SELECT has_server_privilege(
(SELECT oid FROM pg_foreign_server WHERE srvname='s8'), 'USAGE');
has_server_privilege
----------------------
t
(1 row)
SELECT has_server_privilege(
(SELECT oid FROM pg_roles WHERE rolname='regress_test_role'), 's8', 'USAGE');
has_server_privilege
----------------------
f
(1 row)
SELECT has_server_privilege('s8', 'USAGE');
has_server_privilege
----------------------
t
(1 row)
GRANT USAGE ON FOREIGN SERVER s8 TO regress_test_role;
SELECT has_server_privilege('regress_test_role', 's8', 'USAGE');
has_server_privilege
----------------------
t
(1 row)
REVOKE USAGE ON FOREIGN SERVER s8 FROM regress_test_role;
GRANT USAGE ON FOREIGN SERVER s4 TO regress_test_role;
DROP USER MAPPING FOR public SERVER s4;
ALTER SERVER s6 OPTIONS (DROP host, DROP dbname);
ALTER USER MAPPING FOR regress_test_role SERVER s6 OPTIONS (DROP username);
2009-02-24 11:06:36 +01:00
ALTER FOREIGN DATA WRAPPER foo VALIDATOR postgresql_fdw_validator;
WARNING: changing the foreign-data wrapper validator can cause the options for dependent objects to become invalid
2008-12-19 17:25:19 +01:00
-- Privileges
2016-07-18 00:42:31 +02:00
SET ROLE regress_unprivileged_role;
2009-02-24 11:06:36 +01:00
CREATE FOREIGN DATA WRAPPER foobar; -- ERROR
2008-12-19 17:25:19 +01:00
ERROR: permission denied to create foreign-data wrapper "foobar"
HINT: Must be superuser to create a foreign-data wrapper.
ALTER FOREIGN DATA WRAPPER foo OPTIONS (gotcha 'true'); -- ERROR
ERROR: permission denied to alter foreign-data wrapper "foo"
HINT: Must be superuser to alter a foreign-data wrapper.
2016-07-18 00:42:31 +02:00
ALTER FOREIGN DATA WRAPPER foo OWNER TO regress_unprivileged_role; -- ERROR
2008-12-19 17:25:19 +01:00
ERROR: permission denied to change owner of foreign-data wrapper "foo"
HINT: Must be superuser to change owner of a foreign-data wrapper.
DROP FOREIGN DATA WRAPPER foo; -- ERROR
2011-11-18 03:31:29 +01:00
ERROR: must be owner of foreign-data wrapper foo
2008-12-19 17:25:19 +01:00
GRANT USAGE ON FOREIGN DATA WRAPPER foo TO regress_test_role; -- ERROR
ERROR: permission denied for foreign-data wrapper foo
CREATE SERVER s9 FOREIGN DATA WRAPPER foo; -- ERROR
ERROR: permission denied for foreign-data wrapper foo
ALTER SERVER s4 VERSION '0.5'; -- ERROR
ERROR: must be owner of foreign server s4
2016-07-18 00:42:31 +02:00
ALTER SERVER s4 OWNER TO regress_unprivileged_role; -- ERROR
2008-12-19 17:25:19 +01:00
ERROR: must be owner of foreign server s4
DROP SERVER s4; -- ERROR
ERROR: must be owner of foreign server s4
GRANT USAGE ON FOREIGN SERVER s4 TO regress_test_role; -- ERROR
ERROR: permission denied for foreign server s4
CREATE USER MAPPING FOR public SERVER s4; -- ERROR
ERROR: must be owner of foreign server s4
ALTER USER MAPPING FOR regress_test_role SERVER s6 OPTIONS (gotcha 'true'); -- ERROR
ERROR: must be owner of foreign server s6
DROP USER MAPPING FOR regress_test_role SERVER s6; -- ERROR
ERROR: must be owner of foreign server s6
RESET ROLE;
2016-07-18 00:42:31 +02:00
GRANT USAGE ON FOREIGN DATA WRAPPER postgresql TO regress_unprivileged_role;
GRANT USAGE ON FOREIGN DATA WRAPPER foo TO regress_unprivileged_role WITH GRANT OPTION;
SET ROLE regress_unprivileged_role;
2009-02-24 11:06:36 +01:00
CREATE FOREIGN DATA WRAPPER foobar; -- ERROR
2008-12-19 17:25:19 +01:00
ERROR: permission denied to create foreign-data wrapper "foobar"
HINT: Must be superuser to create a foreign-data wrapper.
ALTER FOREIGN DATA WRAPPER foo OPTIONS (gotcha 'true'); -- ERROR
ERROR: permission denied to alter foreign-data wrapper "foo"
HINT: Must be superuser to alter a foreign-data wrapper.
DROP FOREIGN DATA WRAPPER foo; -- ERROR
2011-11-18 03:31:29 +01:00
ERROR: must be owner of foreign-data wrapper foo
2008-12-19 17:25:19 +01:00
GRANT USAGE ON FOREIGN DATA WRAPPER postgresql TO regress_test_role; -- WARNING
WARNING: no privileges were granted for "postgresql"
GRANT USAGE ON FOREIGN DATA WRAPPER foo TO regress_test_role;
CREATE SERVER s9 FOREIGN DATA WRAPPER postgresql;
ALTER SERVER s6 VERSION '0.5'; -- ERROR
ERROR: must be owner of foreign server s6
DROP SERVER s6; -- ERROR
ERROR: must be owner of foreign server s6
GRANT USAGE ON FOREIGN SERVER s6 TO regress_test_role; -- ERROR
ERROR: permission denied for foreign server s6
GRANT USAGE ON FOREIGN SERVER s9 TO regress_test_role;
CREATE USER MAPPING FOR public SERVER s6; -- ERROR
ERROR: must be owner of foreign server s6
CREATE USER MAPPING FOR public SERVER s9;
ALTER USER MAPPING FOR regress_test_role SERVER s6 OPTIONS (gotcha 'true'); -- ERROR
ERROR: must be owner of foreign server s6
DROP USER MAPPING FOR regress_test_role SERVER s6; -- ERROR
ERROR: must be owner of foreign server s6
RESET ROLE;
2016-07-18 00:42:31 +02:00
REVOKE USAGE ON FOREIGN DATA WRAPPER foo FROM regress_unprivileged_role; -- ERROR
2008-12-19 17:25:19 +01:00
ERROR: dependent privileges exist
HINT: Use CASCADE to revoke them too.
2016-07-18 00:42:31 +02:00
REVOKE USAGE ON FOREIGN DATA WRAPPER foo FROM regress_unprivileged_role CASCADE;
SET ROLE regress_unprivileged_role;
2008-12-19 17:25:19 +01:00
GRANT USAGE ON FOREIGN DATA WRAPPER foo TO regress_test_role; -- ERROR
ERROR: permission denied for foreign-data wrapper foo
CREATE SERVER s10 FOREIGN DATA WRAPPER foo; -- ERROR
ERROR: permission denied for foreign-data wrapper foo
ALTER SERVER s9 VERSION '1.1';
GRANT USAGE ON FOREIGN SERVER s9 TO regress_test_role;
CREATE USER MAPPING FOR current_user SERVER s9;
DROP SERVER s9 CASCADE;
NOTICE: drop cascades to 2 other objects
2015-03-05 22:03:16 +01:00
DETAIL: drop cascades to user mapping for public on server s9
2016-07-18 00:42:31 +02:00
drop cascades to user mapping for regress_unprivileged_role on server s9
2008-12-19 17:25:19 +01:00
RESET ROLE;
CREATE SERVER s9 FOREIGN DATA WRAPPER foo;
2016-07-18 00:42:31 +02:00
GRANT USAGE ON FOREIGN SERVER s9 TO regress_unprivileged_role;
SET ROLE regress_unprivileged_role;
2008-12-19 17:25:19 +01:00
ALTER SERVER s9 VERSION '1.2'; -- ERROR
ERROR: must be owner of foreign server s9
GRANT USAGE ON FOREIGN SERVER s9 TO regress_test_role; -- WARNING
WARNING: no privileges were granted for "s9"
2009-01-20 10:10:20 +01:00
CREATE USER MAPPING FOR current_user SERVER s9;
2008-12-19 17:25:19 +01:00
DROP SERVER s9 CASCADE; -- ERROR
ERROR: must be owner of foreign server s9
RESET ROLE;
2014-03-23 07:16:34 +01:00
-- Triggers
CREATE FUNCTION dummy_trigger() RETURNS TRIGGER AS $$
BEGIN
RETURN NULL;
END
$$ language plpgsql;
CREATE TRIGGER trigtest_before_stmt BEFORE INSERT OR UPDATE OR DELETE
ON foreign_schema.foreign_table_1
FOR EACH STATEMENT
EXECUTE PROCEDURE dummy_trigger();
CREATE TRIGGER trigtest_after_stmt AFTER INSERT OR UPDATE OR DELETE
ON foreign_schema.foreign_table_1
FOR EACH STATEMENT
EXECUTE PROCEDURE dummy_trigger();
CREATE TRIGGER trigtest_before_row BEFORE INSERT OR UPDATE OR DELETE
ON foreign_schema.foreign_table_1
FOR EACH ROW
EXECUTE PROCEDURE dummy_trigger();
CREATE TRIGGER trigtest_after_row AFTER INSERT OR UPDATE OR DELETE
ON foreign_schema.foreign_table_1
FOR EACH ROW
EXECUTE PROCEDURE dummy_trigger();
CREATE CONSTRAINT TRIGGER trigtest_constraint AFTER INSERT OR UPDATE OR DELETE
ON foreign_schema.foreign_table_1
FOR EACH ROW
EXECUTE PROCEDURE dummy_trigger();
ERROR: "foreign_table_1" is a foreign table
DETAIL: Foreign tables cannot have constraint triggers.
ALTER FOREIGN TABLE foreign_schema.foreign_table_1
DISABLE TRIGGER trigtest_before_stmt;
ALTER FOREIGN TABLE foreign_schema.foreign_table_1
ENABLE TRIGGER trigtest_before_stmt;
DROP TRIGGER trigtest_before_stmt ON foreign_schema.foreign_table_1;
DROP TRIGGER trigtest_before_row ON foreign_schema.foreign_table_1;
DROP TRIGGER trigtest_after_stmt ON foreign_schema.foreign_table_1;
DROP TRIGGER trigtest_after_row ON foreign_schema.foreign_table_1;
DROP FUNCTION dummy_trigger();
Allow foreign tables to participate in inheritance.
Foreign tables can now be inheritance children, or parents. Much of the
system was already ready for this, but we had to fix a few things of
course, mostly in the area of planner and executor handling of row locks.
As side effects of this, allow foreign tables to have NOT VALID CHECK
constraints (and hence to accept ALTER ... VALIDATE CONSTRAINT), and to
accept ALTER SET STORAGE and ALTER SET WITH/WITHOUT OIDS. Continuing to
disallow these things would've required bizarre and inconsistent special
cases in inheritance behavior. Since foreign tables don't enforce CHECK
constraints anyway, a NOT VALID one is a complete no-op, but that doesn't
mean we shouldn't allow it. And it's possible that some FDWs might have
use for SET STORAGE or SET WITH OIDS, though doubtless they will be no-ops
for most.
An additional change in support of this is that when a ModifyTable node
has multiple target tables, they will all now be explicitly identified
in EXPLAIN output, for example:
Update on pt1 (cost=0.00..321.05 rows=3541 width=46)
Update on pt1
Foreign Update on ft1
Foreign Update on ft2
Update on child3
-> Seq Scan on pt1 (cost=0.00..0.00 rows=1 width=46)
-> Foreign Scan on ft1 (cost=100.00..148.03 rows=1170 width=46)
-> Foreign Scan on ft2 (cost=100.00..148.03 rows=1170 width=46)
-> Seq Scan on child3 (cost=0.00..25.00 rows=1200 width=46)
This was done mainly to provide an unambiguous place to attach "Remote SQL"
fields, but it is useful for inherited updates even when no foreign tables
are involved.
Shigeru Hanada and Etsuro Fujita, reviewed by Ashutosh Bapat and Kyotaro
Horiguchi, some additional hacking by me
2015-03-22 18:53:11 +01:00
-- Table inheritance
CREATE TABLE pt1 (
c1 integer NOT NULL,
c2 text,
c3 date
);
CREATE FOREIGN TABLE ft2 () INHERITS (pt1)
SERVER s0 OPTIONS (delimiter ',', quote '"', "be quoted" 'value');
\d+ pt1
2016-11-03 17:00:00 +01:00
Table "public.pt1"
Column | Type | Collation | Nullable | Default | Storage | Stats target | Description
--------+---------+-----------+----------+---------+----------+--------------+-------------
c1 | integer | | not null | | plain | |
c2 | text | | | | extended | |
c3 | date | | | | plain | |
Allow foreign tables to participate in inheritance.
Foreign tables can now be inheritance children, or parents. Much of the
system was already ready for this, but we had to fix a few things of
course, mostly in the area of planner and executor handling of row locks.
As side effects of this, allow foreign tables to have NOT VALID CHECK
constraints (and hence to accept ALTER ... VALIDATE CONSTRAINT), and to
accept ALTER SET STORAGE and ALTER SET WITH/WITHOUT OIDS. Continuing to
disallow these things would've required bizarre and inconsistent special
cases in inheritance behavior. Since foreign tables don't enforce CHECK
constraints anyway, a NOT VALID one is a complete no-op, but that doesn't
mean we shouldn't allow it. And it's possible that some FDWs might have
use for SET STORAGE or SET WITH OIDS, though doubtless they will be no-ops
for most.
An additional change in support of this is that when a ModifyTable node
has multiple target tables, they will all now be explicitly identified
in EXPLAIN output, for example:
Update on pt1 (cost=0.00..321.05 rows=3541 width=46)
Update on pt1
Foreign Update on ft1
Foreign Update on ft2
Update on child3
-> Seq Scan on pt1 (cost=0.00..0.00 rows=1 width=46)
-> Foreign Scan on ft1 (cost=100.00..148.03 rows=1170 width=46)
-> Foreign Scan on ft2 (cost=100.00..148.03 rows=1170 width=46)
-> Seq Scan on child3 (cost=0.00..25.00 rows=1200 width=46)
This was done mainly to provide an unambiguous place to attach "Remote SQL"
fields, but it is useful for inherited updates even when no foreign tables
are involved.
Shigeru Hanada and Etsuro Fujita, reviewed by Ashutosh Bapat and Kyotaro
Horiguchi, some additional hacking by me
2015-03-22 18:53:11 +01:00
Child tables: ft2
\d+ ft2
2016-11-03 17:00:00 +01:00
Foreign table "public.ft2"
Column | Type | Collation | Nullable | Default | FDW Options | Storage | Stats target | Description
--------+---------+-----------+----------+---------+-------------+----------+--------------+-------------
c1 | integer | | not null | | | plain | |
c2 | text | | | | | extended | |
c3 | date | | | | | plain | |
Allow foreign tables to participate in inheritance.
Foreign tables can now be inheritance children, or parents. Much of the
system was already ready for this, but we had to fix a few things of
course, mostly in the area of planner and executor handling of row locks.
As side effects of this, allow foreign tables to have NOT VALID CHECK
constraints (and hence to accept ALTER ... VALIDATE CONSTRAINT), and to
accept ALTER SET STORAGE and ALTER SET WITH/WITHOUT OIDS. Continuing to
disallow these things would've required bizarre and inconsistent special
cases in inheritance behavior. Since foreign tables don't enforce CHECK
constraints anyway, a NOT VALID one is a complete no-op, but that doesn't
mean we shouldn't allow it. And it's possible that some FDWs might have
use for SET STORAGE or SET WITH OIDS, though doubtless they will be no-ops
for most.
An additional change in support of this is that when a ModifyTable node
has multiple target tables, they will all now be explicitly identified
in EXPLAIN output, for example:
Update on pt1 (cost=0.00..321.05 rows=3541 width=46)
Update on pt1
Foreign Update on ft1
Foreign Update on ft2
Update on child3
-> Seq Scan on pt1 (cost=0.00..0.00 rows=1 width=46)
-> Foreign Scan on ft1 (cost=100.00..148.03 rows=1170 width=46)
-> Foreign Scan on ft2 (cost=100.00..148.03 rows=1170 width=46)
-> Seq Scan on child3 (cost=0.00..25.00 rows=1200 width=46)
This was done mainly to provide an unambiguous place to attach "Remote SQL"
fields, but it is useful for inherited updates even when no foreign tables
are involved.
Shigeru Hanada and Etsuro Fujita, reviewed by Ashutosh Bapat and Kyotaro
Horiguchi, some additional hacking by me
2015-03-22 18:53:11 +01:00
Server: s0
FDW Options: (delimiter ',', quote '"', "be quoted" 'value')
Inherits: pt1
DROP FOREIGN TABLE ft2;
\d+ pt1
2016-11-03 17:00:00 +01:00
Table "public.pt1"
Column | Type | Collation | Nullable | Default | Storage | Stats target | Description
--------+---------+-----------+----------+---------+----------+--------------+-------------
c1 | integer | | not null | | plain | |
c2 | text | | | | extended | |
c3 | date | | | | plain | |
Allow foreign tables to participate in inheritance.
Foreign tables can now be inheritance children, or parents. Much of the
system was already ready for this, but we had to fix a few things of
course, mostly in the area of planner and executor handling of row locks.
As side effects of this, allow foreign tables to have NOT VALID CHECK
constraints (and hence to accept ALTER ... VALIDATE CONSTRAINT), and to
accept ALTER SET STORAGE and ALTER SET WITH/WITHOUT OIDS. Continuing to
disallow these things would've required bizarre and inconsistent special
cases in inheritance behavior. Since foreign tables don't enforce CHECK
constraints anyway, a NOT VALID one is a complete no-op, but that doesn't
mean we shouldn't allow it. And it's possible that some FDWs might have
use for SET STORAGE or SET WITH OIDS, though doubtless they will be no-ops
for most.
An additional change in support of this is that when a ModifyTable node
has multiple target tables, they will all now be explicitly identified
in EXPLAIN output, for example:
Update on pt1 (cost=0.00..321.05 rows=3541 width=46)
Update on pt1
Foreign Update on ft1
Foreign Update on ft2
Update on child3
-> Seq Scan on pt1 (cost=0.00..0.00 rows=1 width=46)
-> Foreign Scan on ft1 (cost=100.00..148.03 rows=1170 width=46)
-> Foreign Scan on ft2 (cost=100.00..148.03 rows=1170 width=46)
-> Seq Scan on child3 (cost=0.00..25.00 rows=1200 width=46)
This was done mainly to provide an unambiguous place to attach "Remote SQL"
fields, but it is useful for inherited updates even when no foreign tables
are involved.
Shigeru Hanada and Etsuro Fujita, reviewed by Ashutosh Bapat and Kyotaro
Horiguchi, some additional hacking by me
2015-03-22 18:53:11 +01:00
CREATE FOREIGN TABLE ft2 (
c1 integer NOT NULL,
c2 text,
c3 date
) SERVER s0 OPTIONS (delimiter ',', quote '"', "be quoted" 'value');
\d+ ft2
2016-11-03 17:00:00 +01:00
Foreign table "public.ft2"
Column | Type | Collation | Nullable | Default | FDW Options | Storage | Stats target | Description
--------+---------+-----------+----------+---------+-------------+----------+--------------+-------------
c1 | integer | | not null | | | plain | |
c2 | text | | | | | extended | |
c3 | date | | | | | plain | |
Allow foreign tables to participate in inheritance.
Foreign tables can now be inheritance children, or parents. Much of the
system was already ready for this, but we had to fix a few things of
course, mostly in the area of planner and executor handling of row locks.
As side effects of this, allow foreign tables to have NOT VALID CHECK
constraints (and hence to accept ALTER ... VALIDATE CONSTRAINT), and to
accept ALTER SET STORAGE and ALTER SET WITH/WITHOUT OIDS. Continuing to
disallow these things would've required bizarre and inconsistent special
cases in inheritance behavior. Since foreign tables don't enforce CHECK
constraints anyway, a NOT VALID one is a complete no-op, but that doesn't
mean we shouldn't allow it. And it's possible that some FDWs might have
use for SET STORAGE or SET WITH OIDS, though doubtless they will be no-ops
for most.
An additional change in support of this is that when a ModifyTable node
has multiple target tables, they will all now be explicitly identified
in EXPLAIN output, for example:
Update on pt1 (cost=0.00..321.05 rows=3541 width=46)
Update on pt1
Foreign Update on ft1
Foreign Update on ft2
Update on child3
-> Seq Scan on pt1 (cost=0.00..0.00 rows=1 width=46)
-> Foreign Scan on ft1 (cost=100.00..148.03 rows=1170 width=46)
-> Foreign Scan on ft2 (cost=100.00..148.03 rows=1170 width=46)
-> Seq Scan on child3 (cost=0.00..25.00 rows=1200 width=46)
This was done mainly to provide an unambiguous place to attach "Remote SQL"
fields, but it is useful for inherited updates even when no foreign tables
are involved.
Shigeru Hanada and Etsuro Fujita, reviewed by Ashutosh Bapat and Kyotaro
Horiguchi, some additional hacking by me
2015-03-22 18:53:11 +01:00
Server: s0
FDW Options: (delimiter ',', quote '"', "be quoted" 'value')
ALTER FOREIGN TABLE ft2 INHERIT pt1;
\d+ pt1
2016-11-03 17:00:00 +01:00
Table "public.pt1"
Column | Type | Collation | Nullable | Default | Storage | Stats target | Description
--------+---------+-----------+----------+---------+----------+--------------+-------------
c1 | integer | | not null | | plain | |
c2 | text | | | | extended | |
c3 | date | | | | plain | |
Allow foreign tables to participate in inheritance.
Foreign tables can now be inheritance children, or parents. Much of the
system was already ready for this, but we had to fix a few things of
course, mostly in the area of planner and executor handling of row locks.
As side effects of this, allow foreign tables to have NOT VALID CHECK
constraints (and hence to accept ALTER ... VALIDATE CONSTRAINT), and to
accept ALTER SET STORAGE and ALTER SET WITH/WITHOUT OIDS. Continuing to
disallow these things would've required bizarre and inconsistent special
cases in inheritance behavior. Since foreign tables don't enforce CHECK
constraints anyway, a NOT VALID one is a complete no-op, but that doesn't
mean we shouldn't allow it. And it's possible that some FDWs might have
use for SET STORAGE or SET WITH OIDS, though doubtless they will be no-ops
for most.
An additional change in support of this is that when a ModifyTable node
has multiple target tables, they will all now be explicitly identified
in EXPLAIN output, for example:
Update on pt1 (cost=0.00..321.05 rows=3541 width=46)
Update on pt1
Foreign Update on ft1
Foreign Update on ft2
Update on child3
-> Seq Scan on pt1 (cost=0.00..0.00 rows=1 width=46)
-> Foreign Scan on ft1 (cost=100.00..148.03 rows=1170 width=46)
-> Foreign Scan on ft2 (cost=100.00..148.03 rows=1170 width=46)
-> Seq Scan on child3 (cost=0.00..25.00 rows=1200 width=46)
This was done mainly to provide an unambiguous place to attach "Remote SQL"
fields, but it is useful for inherited updates even when no foreign tables
are involved.
Shigeru Hanada and Etsuro Fujita, reviewed by Ashutosh Bapat and Kyotaro
Horiguchi, some additional hacking by me
2015-03-22 18:53:11 +01:00
Child tables: ft2
\d+ ft2
2016-11-03 17:00:00 +01:00
Foreign table "public.ft2"
Column | Type | Collation | Nullable | Default | FDW Options | Storage | Stats target | Description
--------+---------+-----------+----------+---------+-------------+----------+--------------+-------------
c1 | integer | | not null | | | plain | |
c2 | text | | | | | extended | |
c3 | date | | | | | plain | |
Allow foreign tables to participate in inheritance.
Foreign tables can now be inheritance children, or parents. Much of the
system was already ready for this, but we had to fix a few things of
course, mostly in the area of planner and executor handling of row locks.
As side effects of this, allow foreign tables to have NOT VALID CHECK
constraints (and hence to accept ALTER ... VALIDATE CONSTRAINT), and to
accept ALTER SET STORAGE and ALTER SET WITH/WITHOUT OIDS. Continuing to
disallow these things would've required bizarre and inconsistent special
cases in inheritance behavior. Since foreign tables don't enforce CHECK
constraints anyway, a NOT VALID one is a complete no-op, but that doesn't
mean we shouldn't allow it. And it's possible that some FDWs might have
use for SET STORAGE or SET WITH OIDS, though doubtless they will be no-ops
for most.
An additional change in support of this is that when a ModifyTable node
has multiple target tables, they will all now be explicitly identified
in EXPLAIN output, for example:
Update on pt1 (cost=0.00..321.05 rows=3541 width=46)
Update on pt1
Foreign Update on ft1
Foreign Update on ft2
Update on child3
-> Seq Scan on pt1 (cost=0.00..0.00 rows=1 width=46)
-> Foreign Scan on ft1 (cost=100.00..148.03 rows=1170 width=46)
-> Foreign Scan on ft2 (cost=100.00..148.03 rows=1170 width=46)
-> Seq Scan on child3 (cost=0.00..25.00 rows=1200 width=46)
This was done mainly to provide an unambiguous place to attach "Remote SQL"
fields, but it is useful for inherited updates even when no foreign tables
are involved.
Shigeru Hanada and Etsuro Fujita, reviewed by Ashutosh Bapat and Kyotaro
Horiguchi, some additional hacking by me
2015-03-22 18:53:11 +01:00
Server: s0
FDW Options: (delimiter ',', quote '"', "be quoted" 'value')
Inherits: pt1
CREATE TABLE ct3() INHERITS(ft2);
CREATE FOREIGN TABLE ft3 (
c1 integer NOT NULL,
c2 text,
c3 date
) INHERITS(ft2)
SERVER s0;
NOTICE: merging column "c1" with inherited definition
NOTICE: merging column "c2" with inherited definition
NOTICE: merging column "c3" with inherited definition
\d+ ft2
2016-11-03 17:00:00 +01:00
Foreign table "public.ft2"
Column | Type | Collation | Nullable | Default | FDW Options | Storage | Stats target | Description
--------+---------+-----------+----------+---------+-------------+----------+--------------+-------------
c1 | integer | | not null | | | plain | |
c2 | text | | | | | extended | |
c3 | date | | | | | plain | |
Allow foreign tables to participate in inheritance.
Foreign tables can now be inheritance children, or parents. Much of the
system was already ready for this, but we had to fix a few things of
course, mostly in the area of planner and executor handling of row locks.
As side effects of this, allow foreign tables to have NOT VALID CHECK
constraints (and hence to accept ALTER ... VALIDATE CONSTRAINT), and to
accept ALTER SET STORAGE and ALTER SET WITH/WITHOUT OIDS. Continuing to
disallow these things would've required bizarre and inconsistent special
cases in inheritance behavior. Since foreign tables don't enforce CHECK
constraints anyway, a NOT VALID one is a complete no-op, but that doesn't
mean we shouldn't allow it. And it's possible that some FDWs might have
use for SET STORAGE or SET WITH OIDS, though doubtless they will be no-ops
for most.
An additional change in support of this is that when a ModifyTable node
has multiple target tables, they will all now be explicitly identified
in EXPLAIN output, for example:
Update on pt1 (cost=0.00..321.05 rows=3541 width=46)
Update on pt1
Foreign Update on ft1
Foreign Update on ft2
Update on child3
-> Seq Scan on pt1 (cost=0.00..0.00 rows=1 width=46)
-> Foreign Scan on ft1 (cost=100.00..148.03 rows=1170 width=46)
-> Foreign Scan on ft2 (cost=100.00..148.03 rows=1170 width=46)
-> Seq Scan on child3 (cost=0.00..25.00 rows=1200 width=46)
This was done mainly to provide an unambiguous place to attach "Remote SQL"
fields, but it is useful for inherited updates even when no foreign tables
are involved.
Shigeru Hanada and Etsuro Fujita, reviewed by Ashutosh Bapat and Kyotaro
Horiguchi, some additional hacking by me
2015-03-22 18:53:11 +01:00
Server: s0
FDW Options: (delimiter ',', quote '"', "be quoted" 'value')
Inherits: pt1
Child tables: ct3,
ft3
\d+ ct3
2016-11-03 17:00:00 +01:00
Table "public.ct3"
Column | Type | Collation | Nullable | Default | Storage | Stats target | Description
--------+---------+-----------+----------+---------+----------+--------------+-------------
c1 | integer | | not null | | plain | |
c2 | text | | | | extended | |
c3 | date | | | | plain | |
Allow foreign tables to participate in inheritance.
Foreign tables can now be inheritance children, or parents. Much of the
system was already ready for this, but we had to fix a few things of
course, mostly in the area of planner and executor handling of row locks.
As side effects of this, allow foreign tables to have NOT VALID CHECK
constraints (and hence to accept ALTER ... VALIDATE CONSTRAINT), and to
accept ALTER SET STORAGE and ALTER SET WITH/WITHOUT OIDS. Continuing to
disallow these things would've required bizarre and inconsistent special
cases in inheritance behavior. Since foreign tables don't enforce CHECK
constraints anyway, a NOT VALID one is a complete no-op, but that doesn't
mean we shouldn't allow it. And it's possible that some FDWs might have
use for SET STORAGE or SET WITH OIDS, though doubtless they will be no-ops
for most.
An additional change in support of this is that when a ModifyTable node
has multiple target tables, they will all now be explicitly identified
in EXPLAIN output, for example:
Update on pt1 (cost=0.00..321.05 rows=3541 width=46)
Update on pt1
Foreign Update on ft1
Foreign Update on ft2
Update on child3
-> Seq Scan on pt1 (cost=0.00..0.00 rows=1 width=46)
-> Foreign Scan on ft1 (cost=100.00..148.03 rows=1170 width=46)
-> Foreign Scan on ft2 (cost=100.00..148.03 rows=1170 width=46)
-> Seq Scan on child3 (cost=0.00..25.00 rows=1200 width=46)
This was done mainly to provide an unambiguous place to attach "Remote SQL"
fields, but it is useful for inherited updates even when no foreign tables
are involved.
Shigeru Hanada and Etsuro Fujita, reviewed by Ashutosh Bapat and Kyotaro
Horiguchi, some additional hacking by me
2015-03-22 18:53:11 +01:00
Inherits: ft2
\d+ ft3
2016-11-03 17:00:00 +01:00
Foreign table "public.ft3"
Column | Type | Collation | Nullable | Default | FDW Options | Storage | Stats target | Description
--------+---------+-----------+----------+---------+-------------+----------+--------------+-------------
c1 | integer | | not null | | | plain | |
c2 | text | | | | | extended | |
c3 | date | | | | | plain | |
Allow foreign tables to participate in inheritance.
Foreign tables can now be inheritance children, or parents. Much of the
system was already ready for this, but we had to fix a few things of
course, mostly in the area of planner and executor handling of row locks.
As side effects of this, allow foreign tables to have NOT VALID CHECK
constraints (and hence to accept ALTER ... VALIDATE CONSTRAINT), and to
accept ALTER SET STORAGE and ALTER SET WITH/WITHOUT OIDS. Continuing to
disallow these things would've required bizarre and inconsistent special
cases in inheritance behavior. Since foreign tables don't enforce CHECK
constraints anyway, a NOT VALID one is a complete no-op, but that doesn't
mean we shouldn't allow it. And it's possible that some FDWs might have
use for SET STORAGE or SET WITH OIDS, though doubtless they will be no-ops
for most.
An additional change in support of this is that when a ModifyTable node
has multiple target tables, they will all now be explicitly identified
in EXPLAIN output, for example:
Update on pt1 (cost=0.00..321.05 rows=3541 width=46)
Update on pt1
Foreign Update on ft1
Foreign Update on ft2
Update on child3
-> Seq Scan on pt1 (cost=0.00..0.00 rows=1 width=46)
-> Foreign Scan on ft1 (cost=100.00..148.03 rows=1170 width=46)
-> Foreign Scan on ft2 (cost=100.00..148.03 rows=1170 width=46)
-> Seq Scan on child3 (cost=0.00..25.00 rows=1200 width=46)
This was done mainly to provide an unambiguous place to attach "Remote SQL"
fields, but it is useful for inherited updates even when no foreign tables
are involved.
Shigeru Hanada and Etsuro Fujita, reviewed by Ashutosh Bapat and Kyotaro
Horiguchi, some additional hacking by me
2015-03-22 18:53:11 +01:00
Server: s0
Inherits: ft2
-- add attributes recursively
ALTER TABLE pt1 ADD COLUMN c4 integer;
ALTER TABLE pt1 ADD COLUMN c5 integer DEFAULT 0;
ALTER TABLE pt1 ADD COLUMN c6 integer;
ALTER TABLE pt1 ADD COLUMN c7 integer NOT NULL;
ALTER TABLE pt1 ADD COLUMN c8 integer;
\d+ pt1
2016-11-03 17:00:00 +01:00
Table "public.pt1"
Column | Type | Collation | Nullable | Default | Storage | Stats target | Description
--------+---------+-----------+----------+---------+----------+--------------+-------------
c1 | integer | | not null | | plain | |
c2 | text | | | | extended | |
c3 | date | | | | plain | |
c4 | integer | | | | plain | |
c5 | integer | | | 0 | plain | |
c6 | integer | | | | plain | |
c7 | integer | | not null | | plain | |
c8 | integer | | | | plain | |
Allow foreign tables to participate in inheritance.
Foreign tables can now be inheritance children, or parents. Much of the
system was already ready for this, but we had to fix a few things of
course, mostly in the area of planner and executor handling of row locks.
As side effects of this, allow foreign tables to have NOT VALID CHECK
constraints (and hence to accept ALTER ... VALIDATE CONSTRAINT), and to
accept ALTER SET STORAGE and ALTER SET WITH/WITHOUT OIDS. Continuing to
disallow these things would've required bizarre and inconsistent special
cases in inheritance behavior. Since foreign tables don't enforce CHECK
constraints anyway, a NOT VALID one is a complete no-op, but that doesn't
mean we shouldn't allow it. And it's possible that some FDWs might have
use for SET STORAGE or SET WITH OIDS, though doubtless they will be no-ops
for most.
An additional change in support of this is that when a ModifyTable node
has multiple target tables, they will all now be explicitly identified
in EXPLAIN output, for example:
Update on pt1 (cost=0.00..321.05 rows=3541 width=46)
Update on pt1
Foreign Update on ft1
Foreign Update on ft2
Update on child3
-> Seq Scan on pt1 (cost=0.00..0.00 rows=1 width=46)
-> Foreign Scan on ft1 (cost=100.00..148.03 rows=1170 width=46)
-> Foreign Scan on ft2 (cost=100.00..148.03 rows=1170 width=46)
-> Seq Scan on child3 (cost=0.00..25.00 rows=1200 width=46)
This was done mainly to provide an unambiguous place to attach "Remote SQL"
fields, but it is useful for inherited updates even when no foreign tables
are involved.
Shigeru Hanada and Etsuro Fujita, reviewed by Ashutosh Bapat and Kyotaro
Horiguchi, some additional hacking by me
2015-03-22 18:53:11 +01:00
Child tables: ft2
\d+ ft2
2016-11-03 17:00:00 +01:00
Foreign table "public.ft2"
Column | Type | Collation | Nullable | Default | FDW Options | Storage | Stats target | Description
--------+---------+-----------+----------+---------+-------------+----------+--------------+-------------
c1 | integer | | not null | | | plain | |
c2 | text | | | | | extended | |
c3 | date | | | | | plain | |
c4 | integer | | | | | plain | |
c5 | integer | | | 0 | | plain | |
c6 | integer | | | | | plain | |
c7 | integer | | not null | | | plain | |
c8 | integer | | | | | plain | |
Allow foreign tables to participate in inheritance.
Foreign tables can now be inheritance children, or parents. Much of the
system was already ready for this, but we had to fix a few things of
course, mostly in the area of planner and executor handling of row locks.
As side effects of this, allow foreign tables to have NOT VALID CHECK
constraints (and hence to accept ALTER ... VALIDATE CONSTRAINT), and to
accept ALTER SET STORAGE and ALTER SET WITH/WITHOUT OIDS. Continuing to
disallow these things would've required bizarre and inconsistent special
cases in inheritance behavior. Since foreign tables don't enforce CHECK
constraints anyway, a NOT VALID one is a complete no-op, but that doesn't
mean we shouldn't allow it. And it's possible that some FDWs might have
use for SET STORAGE or SET WITH OIDS, though doubtless they will be no-ops
for most.
An additional change in support of this is that when a ModifyTable node
has multiple target tables, they will all now be explicitly identified
in EXPLAIN output, for example:
Update on pt1 (cost=0.00..321.05 rows=3541 width=46)
Update on pt1
Foreign Update on ft1
Foreign Update on ft2
Update on child3
-> Seq Scan on pt1 (cost=0.00..0.00 rows=1 width=46)
-> Foreign Scan on ft1 (cost=100.00..148.03 rows=1170 width=46)
-> Foreign Scan on ft2 (cost=100.00..148.03 rows=1170 width=46)
-> Seq Scan on child3 (cost=0.00..25.00 rows=1200 width=46)
This was done mainly to provide an unambiguous place to attach "Remote SQL"
fields, but it is useful for inherited updates even when no foreign tables
are involved.
Shigeru Hanada and Etsuro Fujita, reviewed by Ashutosh Bapat and Kyotaro
Horiguchi, some additional hacking by me
2015-03-22 18:53:11 +01:00
Server: s0
FDW Options: (delimiter ',', quote '"', "be quoted" 'value')
Inherits: pt1
Child tables: ct3,
ft3
\d+ ct3
2016-11-03 17:00:00 +01:00
Table "public.ct3"
Column | Type | Collation | Nullable | Default | Storage | Stats target | Description
--------+---------+-----------+----------+---------+----------+--------------+-------------
c1 | integer | | not null | | plain | |
c2 | text | | | | extended | |
c3 | date | | | | plain | |
c4 | integer | | | | plain | |
c5 | integer | | | 0 | plain | |
c6 | integer | | | | plain | |
c7 | integer | | not null | | plain | |
c8 | integer | | | | plain | |
Allow foreign tables to participate in inheritance.
Foreign tables can now be inheritance children, or parents. Much of the
system was already ready for this, but we had to fix a few things of
course, mostly in the area of planner and executor handling of row locks.
As side effects of this, allow foreign tables to have NOT VALID CHECK
constraints (and hence to accept ALTER ... VALIDATE CONSTRAINT), and to
accept ALTER SET STORAGE and ALTER SET WITH/WITHOUT OIDS. Continuing to
disallow these things would've required bizarre and inconsistent special
cases in inheritance behavior. Since foreign tables don't enforce CHECK
constraints anyway, a NOT VALID one is a complete no-op, but that doesn't
mean we shouldn't allow it. And it's possible that some FDWs might have
use for SET STORAGE or SET WITH OIDS, though doubtless they will be no-ops
for most.
An additional change in support of this is that when a ModifyTable node
has multiple target tables, they will all now be explicitly identified
in EXPLAIN output, for example:
Update on pt1 (cost=0.00..321.05 rows=3541 width=46)
Update on pt1
Foreign Update on ft1
Foreign Update on ft2
Update on child3
-> Seq Scan on pt1 (cost=0.00..0.00 rows=1 width=46)
-> Foreign Scan on ft1 (cost=100.00..148.03 rows=1170 width=46)
-> Foreign Scan on ft2 (cost=100.00..148.03 rows=1170 width=46)
-> Seq Scan on child3 (cost=0.00..25.00 rows=1200 width=46)
This was done mainly to provide an unambiguous place to attach "Remote SQL"
fields, but it is useful for inherited updates even when no foreign tables
are involved.
Shigeru Hanada and Etsuro Fujita, reviewed by Ashutosh Bapat and Kyotaro
Horiguchi, some additional hacking by me
2015-03-22 18:53:11 +01:00
Inherits: ft2
\d+ ft3
2016-11-03 17:00:00 +01:00
Foreign table "public.ft3"
Column | Type | Collation | Nullable | Default | FDW Options | Storage | Stats target | Description
--------+---------+-----------+----------+---------+-------------+----------+--------------+-------------
c1 | integer | | not null | | | plain | |
c2 | text | | | | | extended | |
c3 | date | | | | | plain | |
c4 | integer | | | | | plain | |
c5 | integer | | | 0 | | plain | |
c6 | integer | | | | | plain | |
c7 | integer | | not null | | | plain | |
c8 | integer | | | | | plain | |
Allow foreign tables to participate in inheritance.
Foreign tables can now be inheritance children, or parents. Much of the
system was already ready for this, but we had to fix a few things of
course, mostly in the area of planner and executor handling of row locks.
As side effects of this, allow foreign tables to have NOT VALID CHECK
constraints (and hence to accept ALTER ... VALIDATE CONSTRAINT), and to
accept ALTER SET STORAGE and ALTER SET WITH/WITHOUT OIDS. Continuing to
disallow these things would've required bizarre and inconsistent special
cases in inheritance behavior. Since foreign tables don't enforce CHECK
constraints anyway, a NOT VALID one is a complete no-op, but that doesn't
mean we shouldn't allow it. And it's possible that some FDWs might have
use for SET STORAGE or SET WITH OIDS, though doubtless they will be no-ops
for most.
An additional change in support of this is that when a ModifyTable node
has multiple target tables, they will all now be explicitly identified
in EXPLAIN output, for example:
Update on pt1 (cost=0.00..321.05 rows=3541 width=46)
Update on pt1
Foreign Update on ft1
Foreign Update on ft2
Update on child3
-> Seq Scan on pt1 (cost=0.00..0.00 rows=1 width=46)
-> Foreign Scan on ft1 (cost=100.00..148.03 rows=1170 width=46)
-> Foreign Scan on ft2 (cost=100.00..148.03 rows=1170 width=46)
-> Seq Scan on child3 (cost=0.00..25.00 rows=1200 width=46)
This was done mainly to provide an unambiguous place to attach "Remote SQL"
fields, but it is useful for inherited updates even when no foreign tables
are involved.
Shigeru Hanada and Etsuro Fujita, reviewed by Ashutosh Bapat and Kyotaro
Horiguchi, some additional hacking by me
2015-03-22 18:53:11 +01:00
Server: s0
Inherits: ft2
-- alter attributes recursively
ALTER TABLE pt1 ALTER COLUMN c4 SET DEFAULT 0;
ALTER TABLE pt1 ALTER COLUMN c5 DROP DEFAULT;
ALTER TABLE pt1 ALTER COLUMN c6 SET NOT NULL;
ALTER TABLE pt1 ALTER COLUMN c7 DROP NOT NULL;
ALTER TABLE pt1 ALTER COLUMN c8 TYPE char(10) USING '0'; -- ERROR
ERROR: "ft2" is not a table
ALTER TABLE pt1 ALTER COLUMN c8 TYPE char(10);
ALTER TABLE pt1 ALTER COLUMN c8 SET DATA TYPE text;
ALTER TABLE pt1 ALTER COLUMN c1 SET STATISTICS 10000;
ALTER TABLE pt1 ALTER COLUMN c1 SET (n_distinct = 100);
ALTER TABLE pt1 ALTER COLUMN c8 SET STATISTICS -1;
ALTER TABLE pt1 ALTER COLUMN c8 SET STORAGE EXTERNAL;
\d+ pt1
2016-11-03 17:00:00 +01:00
Table "public.pt1"
Column | Type | Collation | Nullable | Default | Storage | Stats target | Description
--------+---------+-----------+----------+---------+----------+--------------+-------------
c1 | integer | | not null | | plain | 10000 |
c2 | text | | | | extended | |
c3 | date | | | | plain | |
c4 | integer | | | 0 | plain | |
c5 | integer | | | | plain | |
c6 | integer | | not null | | plain | |
c7 | integer | | | | plain | |
c8 | text | | | | external | |
Allow foreign tables to participate in inheritance.
Foreign tables can now be inheritance children, or parents. Much of the
system was already ready for this, but we had to fix a few things of
course, mostly in the area of planner and executor handling of row locks.
As side effects of this, allow foreign tables to have NOT VALID CHECK
constraints (and hence to accept ALTER ... VALIDATE CONSTRAINT), and to
accept ALTER SET STORAGE and ALTER SET WITH/WITHOUT OIDS. Continuing to
disallow these things would've required bizarre and inconsistent special
cases in inheritance behavior. Since foreign tables don't enforce CHECK
constraints anyway, a NOT VALID one is a complete no-op, but that doesn't
mean we shouldn't allow it. And it's possible that some FDWs might have
use for SET STORAGE or SET WITH OIDS, though doubtless they will be no-ops
for most.
An additional change in support of this is that when a ModifyTable node
has multiple target tables, they will all now be explicitly identified
in EXPLAIN output, for example:
Update on pt1 (cost=0.00..321.05 rows=3541 width=46)
Update on pt1
Foreign Update on ft1
Foreign Update on ft2
Update on child3
-> Seq Scan on pt1 (cost=0.00..0.00 rows=1 width=46)
-> Foreign Scan on ft1 (cost=100.00..148.03 rows=1170 width=46)
-> Foreign Scan on ft2 (cost=100.00..148.03 rows=1170 width=46)
-> Seq Scan on child3 (cost=0.00..25.00 rows=1200 width=46)
This was done mainly to provide an unambiguous place to attach "Remote SQL"
fields, but it is useful for inherited updates even when no foreign tables
are involved.
Shigeru Hanada and Etsuro Fujita, reviewed by Ashutosh Bapat and Kyotaro
Horiguchi, some additional hacking by me
2015-03-22 18:53:11 +01:00
Child tables: ft2
\d+ ft2
2016-11-03 17:00:00 +01:00
Foreign table "public.ft2"
Column | Type | Collation | Nullable | Default | FDW Options | Storage | Stats target | Description
--------+---------+-----------+----------+---------+-------------+----------+--------------+-------------
c1 | integer | | not null | | | plain | 10000 |
c2 | text | | | | | extended | |
c3 | date | | | | | plain | |
c4 | integer | | | 0 | | plain | |
c5 | integer | | | | | plain | |
c6 | integer | | not null | | | plain | |
c7 | integer | | | | | plain | |
c8 | text | | | | | external | |
Allow foreign tables to participate in inheritance.
Foreign tables can now be inheritance children, or parents. Much of the
system was already ready for this, but we had to fix a few things of
course, mostly in the area of planner and executor handling of row locks.
As side effects of this, allow foreign tables to have NOT VALID CHECK
constraints (and hence to accept ALTER ... VALIDATE CONSTRAINT), and to
accept ALTER SET STORAGE and ALTER SET WITH/WITHOUT OIDS. Continuing to
disallow these things would've required bizarre and inconsistent special
cases in inheritance behavior. Since foreign tables don't enforce CHECK
constraints anyway, a NOT VALID one is a complete no-op, but that doesn't
mean we shouldn't allow it. And it's possible that some FDWs might have
use for SET STORAGE or SET WITH OIDS, though doubtless they will be no-ops
for most.
An additional change in support of this is that when a ModifyTable node
has multiple target tables, they will all now be explicitly identified
in EXPLAIN output, for example:
Update on pt1 (cost=0.00..321.05 rows=3541 width=46)
Update on pt1
Foreign Update on ft1
Foreign Update on ft2
Update on child3
-> Seq Scan on pt1 (cost=0.00..0.00 rows=1 width=46)
-> Foreign Scan on ft1 (cost=100.00..148.03 rows=1170 width=46)
-> Foreign Scan on ft2 (cost=100.00..148.03 rows=1170 width=46)
-> Seq Scan on child3 (cost=0.00..25.00 rows=1200 width=46)
This was done mainly to provide an unambiguous place to attach "Remote SQL"
fields, but it is useful for inherited updates even when no foreign tables
are involved.
Shigeru Hanada and Etsuro Fujita, reviewed by Ashutosh Bapat and Kyotaro
Horiguchi, some additional hacking by me
2015-03-22 18:53:11 +01:00
Server: s0
FDW Options: (delimiter ',', quote '"', "be quoted" 'value')
Inherits: pt1
Child tables: ct3,
ft3
-- drop attributes recursively
ALTER TABLE pt1 DROP COLUMN c4;
ALTER TABLE pt1 DROP COLUMN c5;
ALTER TABLE pt1 DROP COLUMN c6;
ALTER TABLE pt1 DROP COLUMN c7;
ALTER TABLE pt1 DROP COLUMN c8;
\d+ pt1
2016-11-03 17:00:00 +01:00
Table "public.pt1"
Column | Type | Collation | Nullable | Default | Storage | Stats target | Description
--------+---------+-----------+----------+---------+----------+--------------+-------------
c1 | integer | | not null | | plain | 10000 |
c2 | text | | | | extended | |
c3 | date | | | | plain | |
Allow foreign tables to participate in inheritance.
Foreign tables can now be inheritance children, or parents. Much of the
system was already ready for this, but we had to fix a few things of
course, mostly in the area of planner and executor handling of row locks.
As side effects of this, allow foreign tables to have NOT VALID CHECK
constraints (and hence to accept ALTER ... VALIDATE CONSTRAINT), and to
accept ALTER SET STORAGE and ALTER SET WITH/WITHOUT OIDS. Continuing to
disallow these things would've required bizarre and inconsistent special
cases in inheritance behavior. Since foreign tables don't enforce CHECK
constraints anyway, a NOT VALID one is a complete no-op, but that doesn't
mean we shouldn't allow it. And it's possible that some FDWs might have
use for SET STORAGE or SET WITH OIDS, though doubtless they will be no-ops
for most.
An additional change in support of this is that when a ModifyTable node
has multiple target tables, they will all now be explicitly identified
in EXPLAIN output, for example:
Update on pt1 (cost=0.00..321.05 rows=3541 width=46)
Update on pt1
Foreign Update on ft1
Foreign Update on ft2
Update on child3
-> Seq Scan on pt1 (cost=0.00..0.00 rows=1 width=46)
-> Foreign Scan on ft1 (cost=100.00..148.03 rows=1170 width=46)
-> Foreign Scan on ft2 (cost=100.00..148.03 rows=1170 width=46)
-> Seq Scan on child3 (cost=0.00..25.00 rows=1200 width=46)
This was done mainly to provide an unambiguous place to attach "Remote SQL"
fields, but it is useful for inherited updates even when no foreign tables
are involved.
Shigeru Hanada and Etsuro Fujita, reviewed by Ashutosh Bapat and Kyotaro
Horiguchi, some additional hacking by me
2015-03-22 18:53:11 +01:00
Child tables: ft2
\d+ ft2
2016-11-03 17:00:00 +01:00
Foreign table "public.ft2"
Column | Type | Collation | Nullable | Default | FDW Options | Storage | Stats target | Description
--------+---------+-----------+----------+---------+-------------+----------+--------------+-------------
c1 | integer | | not null | | | plain | 10000 |
c2 | text | | | | | extended | |
c3 | date | | | | | plain | |
Allow foreign tables to participate in inheritance.
Foreign tables can now be inheritance children, or parents. Much of the
system was already ready for this, but we had to fix a few things of
course, mostly in the area of planner and executor handling of row locks.
As side effects of this, allow foreign tables to have NOT VALID CHECK
constraints (and hence to accept ALTER ... VALIDATE CONSTRAINT), and to
accept ALTER SET STORAGE and ALTER SET WITH/WITHOUT OIDS. Continuing to
disallow these things would've required bizarre and inconsistent special
cases in inheritance behavior. Since foreign tables don't enforce CHECK
constraints anyway, a NOT VALID one is a complete no-op, but that doesn't
mean we shouldn't allow it. And it's possible that some FDWs might have
use for SET STORAGE or SET WITH OIDS, though doubtless they will be no-ops
for most.
An additional change in support of this is that when a ModifyTable node
has multiple target tables, they will all now be explicitly identified
in EXPLAIN output, for example:
Update on pt1 (cost=0.00..321.05 rows=3541 width=46)
Update on pt1
Foreign Update on ft1
Foreign Update on ft2
Update on child3
-> Seq Scan on pt1 (cost=0.00..0.00 rows=1 width=46)
-> Foreign Scan on ft1 (cost=100.00..148.03 rows=1170 width=46)
-> Foreign Scan on ft2 (cost=100.00..148.03 rows=1170 width=46)
-> Seq Scan on child3 (cost=0.00..25.00 rows=1200 width=46)
This was done mainly to provide an unambiguous place to attach "Remote SQL"
fields, but it is useful for inherited updates even when no foreign tables
are involved.
Shigeru Hanada and Etsuro Fujita, reviewed by Ashutosh Bapat and Kyotaro
Horiguchi, some additional hacking by me
2015-03-22 18:53:11 +01:00
Server: s0
FDW Options: (delimiter ',', quote '"', "be quoted" 'value')
Inherits: pt1
Child tables: ct3,
ft3
-- add constraints recursively
ALTER TABLE pt1 ADD CONSTRAINT pt1chk1 CHECK (c1 > 0) NO INHERIT;
ALTER TABLE pt1 ADD CONSTRAINT pt1chk2 CHECK (c2 <> '');
-- connoinherit should be true for NO INHERIT constraint
SELECT relname, conname, contype, conislocal, coninhcount, connoinherit
FROM pg_class AS pc JOIN pg_constraint AS pgc ON (conrelid = pc.oid)
WHERE pc.relname = 'pt1'
ORDER BY 1,2;
relname | conname | contype | conislocal | coninhcount | connoinherit
---------+---------+---------+------------+-------------+--------------
pt1 | pt1chk1 | c | t | 0 | t
pt1 | pt1chk2 | c | t | 0 | f
(2 rows)
-- child does not inherit NO INHERIT constraints
\d+ pt1
2016-11-03 17:00:00 +01:00
Table "public.pt1"
Column | Type | Collation | Nullable | Default | Storage | Stats target | Description
--------+---------+-----------+----------+---------+----------+--------------+-------------
c1 | integer | | not null | | plain | 10000 |
c2 | text | | | | extended | |
c3 | date | | | | plain | |
Allow foreign tables to participate in inheritance.
Foreign tables can now be inheritance children, or parents. Much of the
system was already ready for this, but we had to fix a few things of
course, mostly in the area of planner and executor handling of row locks.
As side effects of this, allow foreign tables to have NOT VALID CHECK
constraints (and hence to accept ALTER ... VALIDATE CONSTRAINT), and to
accept ALTER SET STORAGE and ALTER SET WITH/WITHOUT OIDS. Continuing to
disallow these things would've required bizarre and inconsistent special
cases in inheritance behavior. Since foreign tables don't enforce CHECK
constraints anyway, a NOT VALID one is a complete no-op, but that doesn't
mean we shouldn't allow it. And it's possible that some FDWs might have
use for SET STORAGE or SET WITH OIDS, though doubtless they will be no-ops
for most.
An additional change in support of this is that when a ModifyTable node
has multiple target tables, they will all now be explicitly identified
in EXPLAIN output, for example:
Update on pt1 (cost=0.00..321.05 rows=3541 width=46)
Update on pt1
Foreign Update on ft1
Foreign Update on ft2
Update on child3
-> Seq Scan on pt1 (cost=0.00..0.00 rows=1 width=46)
-> Foreign Scan on ft1 (cost=100.00..148.03 rows=1170 width=46)
-> Foreign Scan on ft2 (cost=100.00..148.03 rows=1170 width=46)
-> Seq Scan on child3 (cost=0.00..25.00 rows=1200 width=46)
This was done mainly to provide an unambiguous place to attach "Remote SQL"
fields, but it is useful for inherited updates even when no foreign tables
are involved.
Shigeru Hanada and Etsuro Fujita, reviewed by Ashutosh Bapat and Kyotaro
Horiguchi, some additional hacking by me
2015-03-22 18:53:11 +01:00
Check constraints:
"pt1chk1" CHECK (c1 > 0) NO INHERIT
"pt1chk2" CHECK (c2 <> ''::text)
Child tables: ft2
\d+ ft2
2016-11-03 17:00:00 +01:00
Foreign table "public.ft2"
Column | Type | Collation | Nullable | Default | FDW Options | Storage | Stats target | Description
--------+---------+-----------+----------+---------+-------------+----------+--------------+-------------
c1 | integer | | not null | | | plain | 10000 |
c2 | text | | | | | extended | |
c3 | date | | | | | plain | |
Allow foreign tables to participate in inheritance.
Foreign tables can now be inheritance children, or parents. Much of the
system was already ready for this, but we had to fix a few things of
course, mostly in the area of planner and executor handling of row locks.
As side effects of this, allow foreign tables to have NOT VALID CHECK
constraints (and hence to accept ALTER ... VALIDATE CONSTRAINT), and to
accept ALTER SET STORAGE and ALTER SET WITH/WITHOUT OIDS. Continuing to
disallow these things would've required bizarre and inconsistent special
cases in inheritance behavior. Since foreign tables don't enforce CHECK
constraints anyway, a NOT VALID one is a complete no-op, but that doesn't
mean we shouldn't allow it. And it's possible that some FDWs might have
use for SET STORAGE or SET WITH OIDS, though doubtless they will be no-ops
for most.
An additional change in support of this is that when a ModifyTable node
has multiple target tables, they will all now be explicitly identified
in EXPLAIN output, for example:
Update on pt1 (cost=0.00..321.05 rows=3541 width=46)
Update on pt1
Foreign Update on ft1
Foreign Update on ft2
Update on child3
-> Seq Scan on pt1 (cost=0.00..0.00 rows=1 width=46)
-> Foreign Scan on ft1 (cost=100.00..148.03 rows=1170 width=46)
-> Foreign Scan on ft2 (cost=100.00..148.03 rows=1170 width=46)
-> Seq Scan on child3 (cost=0.00..25.00 rows=1200 width=46)
This was done mainly to provide an unambiguous place to attach "Remote SQL"
fields, but it is useful for inherited updates even when no foreign tables
are involved.
Shigeru Hanada and Etsuro Fujita, reviewed by Ashutosh Bapat and Kyotaro
Horiguchi, some additional hacking by me
2015-03-22 18:53:11 +01:00
Check constraints:
"pt1chk2" CHECK (c2 <> ''::text)
Server: s0
FDW Options: (delimiter ',', quote '"', "be quoted" 'value')
Inherits: pt1
Child tables: ct3,
ft3
DROP FOREIGN TABLE ft2; -- ERROR
ERROR: cannot drop foreign table ft2 because other objects depend on it
DETAIL: table ct3 depends on foreign table ft2
foreign table ft3 depends on foreign table ft2
HINT: Use DROP ... CASCADE to drop the dependent objects too.
DROP FOREIGN TABLE ft2 CASCADE;
NOTICE: drop cascades to 2 other objects
DETAIL: drop cascades to table ct3
drop cascades to foreign table ft3
CREATE FOREIGN TABLE ft2 (
c1 integer NOT NULL,
c2 text,
c3 date
) SERVER s0 OPTIONS (delimiter ',', quote '"', "be quoted" 'value');
-- child must have parent's INHERIT constraints
ALTER FOREIGN TABLE ft2 INHERIT pt1; -- ERROR
ERROR: child table is missing constraint "pt1chk2"
ALTER FOREIGN TABLE ft2 ADD CONSTRAINT pt1chk2 CHECK (c2 <> '');
ALTER FOREIGN TABLE ft2 INHERIT pt1;
-- child does not inherit NO INHERIT constraints
\d+ pt1
2016-11-03 17:00:00 +01:00
Table "public.pt1"
Column | Type | Collation | Nullable | Default | Storage | Stats target | Description
--------+---------+-----------+----------+---------+----------+--------------+-------------
c1 | integer | | not null | | plain | 10000 |
c2 | text | | | | extended | |
c3 | date | | | | plain | |
Allow foreign tables to participate in inheritance.
Foreign tables can now be inheritance children, or parents. Much of the
system was already ready for this, but we had to fix a few things of
course, mostly in the area of planner and executor handling of row locks.
As side effects of this, allow foreign tables to have NOT VALID CHECK
constraints (and hence to accept ALTER ... VALIDATE CONSTRAINT), and to
accept ALTER SET STORAGE and ALTER SET WITH/WITHOUT OIDS. Continuing to
disallow these things would've required bizarre and inconsistent special
cases in inheritance behavior. Since foreign tables don't enforce CHECK
constraints anyway, a NOT VALID one is a complete no-op, but that doesn't
mean we shouldn't allow it. And it's possible that some FDWs might have
use for SET STORAGE or SET WITH OIDS, though doubtless they will be no-ops
for most.
An additional change in support of this is that when a ModifyTable node
has multiple target tables, they will all now be explicitly identified
in EXPLAIN output, for example:
Update on pt1 (cost=0.00..321.05 rows=3541 width=46)
Update on pt1
Foreign Update on ft1
Foreign Update on ft2
Update on child3
-> Seq Scan on pt1 (cost=0.00..0.00 rows=1 width=46)
-> Foreign Scan on ft1 (cost=100.00..148.03 rows=1170 width=46)
-> Foreign Scan on ft2 (cost=100.00..148.03 rows=1170 width=46)
-> Seq Scan on child3 (cost=0.00..25.00 rows=1200 width=46)
This was done mainly to provide an unambiguous place to attach "Remote SQL"
fields, but it is useful for inherited updates even when no foreign tables
are involved.
Shigeru Hanada and Etsuro Fujita, reviewed by Ashutosh Bapat and Kyotaro
Horiguchi, some additional hacking by me
2015-03-22 18:53:11 +01:00
Check constraints:
"pt1chk1" CHECK (c1 > 0) NO INHERIT
"pt1chk2" CHECK (c2 <> ''::text)
Child tables: ft2
\d+ ft2
2016-11-03 17:00:00 +01:00
Foreign table "public.ft2"
Column | Type | Collation | Nullable | Default | FDW Options | Storage | Stats target | Description
--------+---------+-----------+----------+---------+-------------+----------+--------------+-------------
c1 | integer | | not null | | | plain | |
c2 | text | | | | | extended | |
c3 | date | | | | | plain | |
Allow foreign tables to participate in inheritance.
Foreign tables can now be inheritance children, or parents. Much of the
system was already ready for this, but we had to fix a few things of
course, mostly in the area of planner and executor handling of row locks.
As side effects of this, allow foreign tables to have NOT VALID CHECK
constraints (and hence to accept ALTER ... VALIDATE CONSTRAINT), and to
accept ALTER SET STORAGE and ALTER SET WITH/WITHOUT OIDS. Continuing to
disallow these things would've required bizarre and inconsistent special
cases in inheritance behavior. Since foreign tables don't enforce CHECK
constraints anyway, a NOT VALID one is a complete no-op, but that doesn't
mean we shouldn't allow it. And it's possible that some FDWs might have
use for SET STORAGE or SET WITH OIDS, though doubtless they will be no-ops
for most.
An additional change in support of this is that when a ModifyTable node
has multiple target tables, they will all now be explicitly identified
in EXPLAIN output, for example:
Update on pt1 (cost=0.00..321.05 rows=3541 width=46)
Update on pt1
Foreign Update on ft1
Foreign Update on ft2
Update on child3
-> Seq Scan on pt1 (cost=0.00..0.00 rows=1 width=46)
-> Foreign Scan on ft1 (cost=100.00..148.03 rows=1170 width=46)
-> Foreign Scan on ft2 (cost=100.00..148.03 rows=1170 width=46)
-> Seq Scan on child3 (cost=0.00..25.00 rows=1200 width=46)
This was done mainly to provide an unambiguous place to attach "Remote SQL"
fields, but it is useful for inherited updates even when no foreign tables
are involved.
Shigeru Hanada and Etsuro Fujita, reviewed by Ashutosh Bapat and Kyotaro
Horiguchi, some additional hacking by me
2015-03-22 18:53:11 +01:00
Check constraints:
"pt1chk2" CHECK (c2 <> ''::text)
Server: s0
FDW Options: (delimiter ',', quote '"', "be quoted" 'value')
Inherits: pt1
-- drop constraints recursively
ALTER TABLE pt1 DROP CONSTRAINT pt1chk1 CASCADE;
ALTER TABLE pt1 DROP CONSTRAINT pt1chk2 CASCADE;
-- NOT VALID case
INSERT INTO pt1 VALUES (1, 'pt1'::text, '1994-01-01'::date);
ALTER TABLE pt1 ADD CONSTRAINT pt1chk3 CHECK (c2 <> '') NOT VALID;
\d+ pt1
2016-11-03 17:00:00 +01:00
Table "public.pt1"
Column | Type | Collation | Nullable | Default | Storage | Stats target | Description
--------+---------+-----------+----------+---------+----------+--------------+-------------
c1 | integer | | not null | | plain | 10000 |
c2 | text | | | | extended | |
c3 | date | | | | plain | |
Allow foreign tables to participate in inheritance.
Foreign tables can now be inheritance children, or parents. Much of the
system was already ready for this, but we had to fix a few things of
course, mostly in the area of planner and executor handling of row locks.
As side effects of this, allow foreign tables to have NOT VALID CHECK
constraints (and hence to accept ALTER ... VALIDATE CONSTRAINT), and to
accept ALTER SET STORAGE and ALTER SET WITH/WITHOUT OIDS. Continuing to
disallow these things would've required bizarre and inconsistent special
cases in inheritance behavior. Since foreign tables don't enforce CHECK
constraints anyway, a NOT VALID one is a complete no-op, but that doesn't
mean we shouldn't allow it. And it's possible that some FDWs might have
use for SET STORAGE or SET WITH OIDS, though doubtless they will be no-ops
for most.
An additional change in support of this is that when a ModifyTable node
has multiple target tables, they will all now be explicitly identified
in EXPLAIN output, for example:
Update on pt1 (cost=0.00..321.05 rows=3541 width=46)
Update on pt1
Foreign Update on ft1
Foreign Update on ft2
Update on child3
-> Seq Scan on pt1 (cost=0.00..0.00 rows=1 width=46)
-> Foreign Scan on ft1 (cost=100.00..148.03 rows=1170 width=46)
-> Foreign Scan on ft2 (cost=100.00..148.03 rows=1170 width=46)
-> Seq Scan on child3 (cost=0.00..25.00 rows=1200 width=46)
This was done mainly to provide an unambiguous place to attach "Remote SQL"
fields, but it is useful for inherited updates even when no foreign tables
are involved.
Shigeru Hanada and Etsuro Fujita, reviewed by Ashutosh Bapat and Kyotaro
Horiguchi, some additional hacking by me
2015-03-22 18:53:11 +01:00
Check constraints:
"pt1chk3" CHECK (c2 <> ''::text) NOT VALID
Child tables: ft2
\d+ ft2
2016-11-03 17:00:00 +01:00
Foreign table "public.ft2"
Column | Type | Collation | Nullable | Default | FDW Options | Storage | Stats target | Description
--------+---------+-----------+----------+---------+-------------+----------+--------------+-------------
c1 | integer | | not null | | | plain | |
c2 | text | | | | | extended | |
c3 | date | | | | | plain | |
Allow foreign tables to participate in inheritance.
Foreign tables can now be inheritance children, or parents. Much of the
system was already ready for this, but we had to fix a few things of
course, mostly in the area of planner and executor handling of row locks.
As side effects of this, allow foreign tables to have NOT VALID CHECK
constraints (and hence to accept ALTER ... VALIDATE CONSTRAINT), and to
accept ALTER SET STORAGE and ALTER SET WITH/WITHOUT OIDS. Continuing to
disallow these things would've required bizarre and inconsistent special
cases in inheritance behavior. Since foreign tables don't enforce CHECK
constraints anyway, a NOT VALID one is a complete no-op, but that doesn't
mean we shouldn't allow it. And it's possible that some FDWs might have
use for SET STORAGE or SET WITH OIDS, though doubtless they will be no-ops
for most.
An additional change in support of this is that when a ModifyTable node
has multiple target tables, they will all now be explicitly identified
in EXPLAIN output, for example:
Update on pt1 (cost=0.00..321.05 rows=3541 width=46)
Update on pt1
Foreign Update on ft1
Foreign Update on ft2
Update on child3
-> Seq Scan on pt1 (cost=0.00..0.00 rows=1 width=46)
-> Foreign Scan on ft1 (cost=100.00..148.03 rows=1170 width=46)
-> Foreign Scan on ft2 (cost=100.00..148.03 rows=1170 width=46)
-> Seq Scan on child3 (cost=0.00..25.00 rows=1200 width=46)
This was done mainly to provide an unambiguous place to attach "Remote SQL"
fields, but it is useful for inherited updates even when no foreign tables
are involved.
Shigeru Hanada and Etsuro Fujita, reviewed by Ashutosh Bapat and Kyotaro
Horiguchi, some additional hacking by me
2015-03-22 18:53:11 +01:00
Check constraints:
"pt1chk2" CHECK (c2 <> ''::text)
"pt1chk3" CHECK (c2 <> ''::text) NOT VALID
Server: s0
FDW Options: (delimiter ',', quote '"', "be quoted" 'value')
Inherits: pt1
-- VALIDATE CONSTRAINT need do nothing on foreign tables
ALTER TABLE pt1 VALIDATE CONSTRAINT pt1chk3;
\d+ pt1
2016-11-03 17:00:00 +01:00
Table "public.pt1"
Column | Type | Collation | Nullable | Default | Storage | Stats target | Description
--------+---------+-----------+----------+---------+----------+--------------+-------------
c1 | integer | | not null | | plain | 10000 |
c2 | text | | | | extended | |
c3 | date | | | | plain | |
Allow foreign tables to participate in inheritance.
Foreign tables can now be inheritance children, or parents. Much of the
system was already ready for this, but we had to fix a few things of
course, mostly in the area of planner and executor handling of row locks.
As side effects of this, allow foreign tables to have NOT VALID CHECK
constraints (and hence to accept ALTER ... VALIDATE CONSTRAINT), and to
accept ALTER SET STORAGE and ALTER SET WITH/WITHOUT OIDS. Continuing to
disallow these things would've required bizarre and inconsistent special
cases in inheritance behavior. Since foreign tables don't enforce CHECK
constraints anyway, a NOT VALID one is a complete no-op, but that doesn't
mean we shouldn't allow it. And it's possible that some FDWs might have
use for SET STORAGE or SET WITH OIDS, though doubtless they will be no-ops
for most.
An additional change in support of this is that when a ModifyTable node
has multiple target tables, they will all now be explicitly identified
in EXPLAIN output, for example:
Update on pt1 (cost=0.00..321.05 rows=3541 width=46)
Update on pt1
Foreign Update on ft1
Foreign Update on ft2
Update on child3
-> Seq Scan on pt1 (cost=0.00..0.00 rows=1 width=46)
-> Foreign Scan on ft1 (cost=100.00..148.03 rows=1170 width=46)
-> Foreign Scan on ft2 (cost=100.00..148.03 rows=1170 width=46)
-> Seq Scan on child3 (cost=0.00..25.00 rows=1200 width=46)
This was done mainly to provide an unambiguous place to attach "Remote SQL"
fields, but it is useful for inherited updates even when no foreign tables
are involved.
Shigeru Hanada and Etsuro Fujita, reviewed by Ashutosh Bapat and Kyotaro
Horiguchi, some additional hacking by me
2015-03-22 18:53:11 +01:00
Check constraints:
"pt1chk3" CHECK (c2 <> ''::text)
Child tables: ft2
\d+ ft2
2016-11-03 17:00:00 +01:00
Foreign table "public.ft2"
Column | Type | Collation | Nullable | Default | FDW Options | Storage | Stats target | Description
--------+---------+-----------+----------+---------+-------------+----------+--------------+-------------
c1 | integer | | not null | | | plain | |
c2 | text | | | | | extended | |
c3 | date | | | | | plain | |
Allow foreign tables to participate in inheritance.
Foreign tables can now be inheritance children, or parents. Much of the
system was already ready for this, but we had to fix a few things of
course, mostly in the area of planner and executor handling of row locks.
As side effects of this, allow foreign tables to have NOT VALID CHECK
constraints (and hence to accept ALTER ... VALIDATE CONSTRAINT), and to
accept ALTER SET STORAGE and ALTER SET WITH/WITHOUT OIDS. Continuing to
disallow these things would've required bizarre and inconsistent special
cases in inheritance behavior. Since foreign tables don't enforce CHECK
constraints anyway, a NOT VALID one is a complete no-op, but that doesn't
mean we shouldn't allow it. And it's possible that some FDWs might have
use for SET STORAGE or SET WITH OIDS, though doubtless they will be no-ops
for most.
An additional change in support of this is that when a ModifyTable node
has multiple target tables, they will all now be explicitly identified
in EXPLAIN output, for example:
Update on pt1 (cost=0.00..321.05 rows=3541 width=46)
Update on pt1
Foreign Update on ft1
Foreign Update on ft2
Update on child3
-> Seq Scan on pt1 (cost=0.00..0.00 rows=1 width=46)
-> Foreign Scan on ft1 (cost=100.00..148.03 rows=1170 width=46)
-> Foreign Scan on ft2 (cost=100.00..148.03 rows=1170 width=46)
-> Seq Scan on child3 (cost=0.00..25.00 rows=1200 width=46)
This was done mainly to provide an unambiguous place to attach "Remote SQL"
fields, but it is useful for inherited updates even when no foreign tables
are involved.
Shigeru Hanada and Etsuro Fujita, reviewed by Ashutosh Bapat and Kyotaro
Horiguchi, some additional hacking by me
2015-03-22 18:53:11 +01:00
Check constraints:
"pt1chk2" CHECK (c2 <> ''::text)
"pt1chk3" CHECK (c2 <> ''::text)
Server: s0
FDW Options: (delimiter ',', quote '"', "be quoted" 'value')
Inherits: pt1
-- OID system column
ALTER TABLE pt1 SET WITH OIDS;
\d+ pt1
2016-11-03 17:00:00 +01:00
Table "public.pt1"
Column | Type | Collation | Nullable | Default | Storage | Stats target | Description
--------+---------+-----------+----------+---------+----------+--------------+-------------
c1 | integer | | not null | | plain | 10000 |
c2 | text | | | | extended | |
c3 | date | | | | plain | |
Allow foreign tables to participate in inheritance.
Foreign tables can now be inheritance children, or parents. Much of the
system was already ready for this, but we had to fix a few things of
course, mostly in the area of planner and executor handling of row locks.
As side effects of this, allow foreign tables to have NOT VALID CHECK
constraints (and hence to accept ALTER ... VALIDATE CONSTRAINT), and to
accept ALTER SET STORAGE and ALTER SET WITH/WITHOUT OIDS. Continuing to
disallow these things would've required bizarre and inconsistent special
cases in inheritance behavior. Since foreign tables don't enforce CHECK
constraints anyway, a NOT VALID one is a complete no-op, but that doesn't
mean we shouldn't allow it. And it's possible that some FDWs might have
use for SET STORAGE or SET WITH OIDS, though doubtless they will be no-ops
for most.
An additional change in support of this is that when a ModifyTable node
has multiple target tables, they will all now be explicitly identified
in EXPLAIN output, for example:
Update on pt1 (cost=0.00..321.05 rows=3541 width=46)
Update on pt1
Foreign Update on ft1
Foreign Update on ft2
Update on child3
-> Seq Scan on pt1 (cost=0.00..0.00 rows=1 width=46)
-> Foreign Scan on ft1 (cost=100.00..148.03 rows=1170 width=46)
-> Foreign Scan on ft2 (cost=100.00..148.03 rows=1170 width=46)
-> Seq Scan on child3 (cost=0.00..25.00 rows=1200 width=46)
This was done mainly to provide an unambiguous place to attach "Remote SQL"
fields, but it is useful for inherited updates even when no foreign tables
are involved.
Shigeru Hanada and Etsuro Fujita, reviewed by Ashutosh Bapat and Kyotaro
Horiguchi, some additional hacking by me
2015-03-22 18:53:11 +01:00
Check constraints:
"pt1chk3" CHECK (c2 <> ''::text)
Child tables: ft2
Has OIDs: yes
\d+ ft2
2016-11-03 17:00:00 +01:00
Foreign table "public.ft2"
Column | Type | Collation | Nullable | Default | FDW Options | Storage | Stats target | Description
--------+---------+-----------+----------+---------+-------------+----------+--------------+-------------
c1 | integer | | not null | | | plain | |
c2 | text | | | | | extended | |
c3 | date | | | | | plain | |
Allow foreign tables to participate in inheritance.
Foreign tables can now be inheritance children, or parents. Much of the
system was already ready for this, but we had to fix a few things of
course, mostly in the area of planner and executor handling of row locks.
As side effects of this, allow foreign tables to have NOT VALID CHECK
constraints (and hence to accept ALTER ... VALIDATE CONSTRAINT), and to
accept ALTER SET STORAGE and ALTER SET WITH/WITHOUT OIDS. Continuing to
disallow these things would've required bizarre and inconsistent special
cases in inheritance behavior. Since foreign tables don't enforce CHECK
constraints anyway, a NOT VALID one is a complete no-op, but that doesn't
mean we shouldn't allow it. And it's possible that some FDWs might have
use for SET STORAGE or SET WITH OIDS, though doubtless they will be no-ops
for most.
An additional change in support of this is that when a ModifyTable node
has multiple target tables, they will all now be explicitly identified
in EXPLAIN output, for example:
Update on pt1 (cost=0.00..321.05 rows=3541 width=46)
Update on pt1
Foreign Update on ft1
Foreign Update on ft2
Update on child3
-> Seq Scan on pt1 (cost=0.00..0.00 rows=1 width=46)
-> Foreign Scan on ft1 (cost=100.00..148.03 rows=1170 width=46)
-> Foreign Scan on ft2 (cost=100.00..148.03 rows=1170 width=46)
-> Seq Scan on child3 (cost=0.00..25.00 rows=1200 width=46)
This was done mainly to provide an unambiguous place to attach "Remote SQL"
fields, but it is useful for inherited updates even when no foreign tables
are involved.
Shigeru Hanada and Etsuro Fujita, reviewed by Ashutosh Bapat and Kyotaro
Horiguchi, some additional hacking by me
2015-03-22 18:53:11 +01:00
Check constraints:
"pt1chk2" CHECK (c2 <> ''::text)
"pt1chk3" CHECK (c2 <> ''::text)
Server: s0
FDW Options: (delimiter ',', quote '"', "be quoted" 'value')
Inherits: pt1
Has OIDs: yes
ALTER TABLE ft2 SET WITHOUT OIDS; -- ERROR
ERROR: cannot drop inherited column "oid"
ALTER TABLE pt1 SET WITHOUT OIDS;
\d+ pt1
2016-11-03 17:00:00 +01:00
Table "public.pt1"
Column | Type | Collation | Nullable | Default | Storage | Stats target | Description
--------+---------+-----------+----------+---------+----------+--------------+-------------
c1 | integer | | not null | | plain | 10000 |
c2 | text | | | | extended | |
c3 | date | | | | plain | |
Allow foreign tables to participate in inheritance.
Foreign tables can now be inheritance children, or parents. Much of the
system was already ready for this, but we had to fix a few things of
course, mostly in the area of planner and executor handling of row locks.
As side effects of this, allow foreign tables to have NOT VALID CHECK
constraints (and hence to accept ALTER ... VALIDATE CONSTRAINT), and to
accept ALTER SET STORAGE and ALTER SET WITH/WITHOUT OIDS. Continuing to
disallow these things would've required bizarre and inconsistent special
cases in inheritance behavior. Since foreign tables don't enforce CHECK
constraints anyway, a NOT VALID one is a complete no-op, but that doesn't
mean we shouldn't allow it. And it's possible that some FDWs might have
use for SET STORAGE or SET WITH OIDS, though doubtless they will be no-ops
for most.
An additional change in support of this is that when a ModifyTable node
has multiple target tables, they will all now be explicitly identified
in EXPLAIN output, for example:
Update on pt1 (cost=0.00..321.05 rows=3541 width=46)
Update on pt1
Foreign Update on ft1
Foreign Update on ft2
Update on child3
-> Seq Scan on pt1 (cost=0.00..0.00 rows=1 width=46)
-> Foreign Scan on ft1 (cost=100.00..148.03 rows=1170 width=46)
-> Foreign Scan on ft2 (cost=100.00..148.03 rows=1170 width=46)
-> Seq Scan on child3 (cost=0.00..25.00 rows=1200 width=46)
This was done mainly to provide an unambiguous place to attach "Remote SQL"
fields, but it is useful for inherited updates even when no foreign tables
are involved.
Shigeru Hanada and Etsuro Fujita, reviewed by Ashutosh Bapat and Kyotaro
Horiguchi, some additional hacking by me
2015-03-22 18:53:11 +01:00
Check constraints:
"pt1chk3" CHECK (c2 <> ''::text)
Child tables: ft2
\d+ ft2
2016-11-03 17:00:00 +01:00
Foreign table "public.ft2"
Column | Type | Collation | Nullable | Default | FDW Options | Storage | Stats target | Description
--------+---------+-----------+----------+---------+-------------+----------+--------------+-------------
c1 | integer | | not null | | | plain | |
c2 | text | | | | | extended | |
c3 | date | | | | | plain | |
Allow foreign tables to participate in inheritance.
Foreign tables can now be inheritance children, or parents. Much of the
system was already ready for this, but we had to fix a few things of
course, mostly in the area of planner and executor handling of row locks.
As side effects of this, allow foreign tables to have NOT VALID CHECK
constraints (and hence to accept ALTER ... VALIDATE CONSTRAINT), and to
accept ALTER SET STORAGE and ALTER SET WITH/WITHOUT OIDS. Continuing to
disallow these things would've required bizarre and inconsistent special
cases in inheritance behavior. Since foreign tables don't enforce CHECK
constraints anyway, a NOT VALID one is a complete no-op, but that doesn't
mean we shouldn't allow it. And it's possible that some FDWs might have
use for SET STORAGE or SET WITH OIDS, though doubtless they will be no-ops
for most.
An additional change in support of this is that when a ModifyTable node
has multiple target tables, they will all now be explicitly identified
in EXPLAIN output, for example:
Update on pt1 (cost=0.00..321.05 rows=3541 width=46)
Update on pt1
Foreign Update on ft1
Foreign Update on ft2
Update on child3
-> Seq Scan on pt1 (cost=0.00..0.00 rows=1 width=46)
-> Foreign Scan on ft1 (cost=100.00..148.03 rows=1170 width=46)
-> Foreign Scan on ft2 (cost=100.00..148.03 rows=1170 width=46)
-> Seq Scan on child3 (cost=0.00..25.00 rows=1200 width=46)
This was done mainly to provide an unambiguous place to attach "Remote SQL"
fields, but it is useful for inherited updates even when no foreign tables
are involved.
Shigeru Hanada and Etsuro Fujita, reviewed by Ashutosh Bapat and Kyotaro
Horiguchi, some additional hacking by me
2015-03-22 18:53:11 +01:00
Check constraints:
"pt1chk2" CHECK (c2 <> ''::text)
"pt1chk3" CHECK (c2 <> ''::text)
Server: s0
FDW Options: (delimiter ',', quote '"', "be quoted" 'value')
Inherits: pt1
-- changes name of an attribute recursively
ALTER TABLE pt1 RENAME COLUMN c1 TO f1;
ALTER TABLE pt1 RENAME COLUMN c2 TO f2;
ALTER TABLE pt1 RENAME COLUMN c3 TO f3;
-- changes name of a constraint recursively
ALTER TABLE pt1 RENAME CONSTRAINT pt1chk3 TO f2_check;
\d+ pt1
2016-11-03 17:00:00 +01:00
Table "public.pt1"
Column | Type | Collation | Nullable | Default | Storage | Stats target | Description
--------+---------+-----------+----------+---------+----------+--------------+-------------
f1 | integer | | not null | | plain | 10000 |
f2 | text | | | | extended | |
f3 | date | | | | plain | |
Allow foreign tables to participate in inheritance.
Foreign tables can now be inheritance children, or parents. Much of the
system was already ready for this, but we had to fix a few things of
course, mostly in the area of planner and executor handling of row locks.
As side effects of this, allow foreign tables to have NOT VALID CHECK
constraints (and hence to accept ALTER ... VALIDATE CONSTRAINT), and to
accept ALTER SET STORAGE and ALTER SET WITH/WITHOUT OIDS. Continuing to
disallow these things would've required bizarre and inconsistent special
cases in inheritance behavior. Since foreign tables don't enforce CHECK
constraints anyway, a NOT VALID one is a complete no-op, but that doesn't
mean we shouldn't allow it. And it's possible that some FDWs might have
use for SET STORAGE or SET WITH OIDS, though doubtless they will be no-ops
for most.
An additional change in support of this is that when a ModifyTable node
has multiple target tables, they will all now be explicitly identified
in EXPLAIN output, for example:
Update on pt1 (cost=0.00..321.05 rows=3541 width=46)
Update on pt1
Foreign Update on ft1
Foreign Update on ft2
Update on child3
-> Seq Scan on pt1 (cost=0.00..0.00 rows=1 width=46)
-> Foreign Scan on ft1 (cost=100.00..148.03 rows=1170 width=46)
-> Foreign Scan on ft2 (cost=100.00..148.03 rows=1170 width=46)
-> Seq Scan on child3 (cost=0.00..25.00 rows=1200 width=46)
This was done mainly to provide an unambiguous place to attach "Remote SQL"
fields, but it is useful for inherited updates even when no foreign tables
are involved.
Shigeru Hanada and Etsuro Fujita, reviewed by Ashutosh Bapat and Kyotaro
Horiguchi, some additional hacking by me
2015-03-22 18:53:11 +01:00
Check constraints:
"f2_check" CHECK (f2 <> ''::text)
Child tables: ft2
\d+ ft2
2016-11-03 17:00:00 +01:00
Foreign table "public.ft2"
Column | Type | Collation | Nullable | Default | FDW Options | Storage | Stats target | Description
--------+---------+-----------+----------+---------+-------------+----------+--------------+-------------
f1 | integer | | not null | | | plain | |
f2 | text | | | | | extended | |
f3 | date | | | | | plain | |
Allow foreign tables to participate in inheritance.
Foreign tables can now be inheritance children, or parents. Much of the
system was already ready for this, but we had to fix a few things of
course, mostly in the area of planner and executor handling of row locks.
As side effects of this, allow foreign tables to have NOT VALID CHECK
constraints (and hence to accept ALTER ... VALIDATE CONSTRAINT), and to
accept ALTER SET STORAGE and ALTER SET WITH/WITHOUT OIDS. Continuing to
disallow these things would've required bizarre and inconsistent special
cases in inheritance behavior. Since foreign tables don't enforce CHECK
constraints anyway, a NOT VALID one is a complete no-op, but that doesn't
mean we shouldn't allow it. And it's possible that some FDWs might have
use for SET STORAGE or SET WITH OIDS, though doubtless they will be no-ops
for most.
An additional change in support of this is that when a ModifyTable node
has multiple target tables, they will all now be explicitly identified
in EXPLAIN output, for example:
Update on pt1 (cost=0.00..321.05 rows=3541 width=46)
Update on pt1
Foreign Update on ft1
Foreign Update on ft2
Update on child3
-> Seq Scan on pt1 (cost=0.00..0.00 rows=1 width=46)
-> Foreign Scan on ft1 (cost=100.00..148.03 rows=1170 width=46)
-> Foreign Scan on ft2 (cost=100.00..148.03 rows=1170 width=46)
-> Seq Scan on child3 (cost=0.00..25.00 rows=1200 width=46)
This was done mainly to provide an unambiguous place to attach "Remote SQL"
fields, but it is useful for inherited updates even when no foreign tables
are involved.
Shigeru Hanada and Etsuro Fujita, reviewed by Ashutosh Bapat and Kyotaro
Horiguchi, some additional hacking by me
2015-03-22 18:53:11 +01:00
Check constraints:
"f2_check" CHECK (f2 <> ''::text)
"pt1chk2" CHECK (f2 <> ''::text)
Server: s0
FDW Options: (delimiter ',', quote '"', "be quoted" 'value')
Inherits: pt1
-- TRUNCATE doesn't work on foreign tables, either directly or recursively
TRUNCATE ft2; -- ERROR
ERROR: "ft2" is not a table
TRUNCATE pt1; -- ERROR
ERROR: "ft2" is not a table
DROP TABLE pt1 CASCADE;
NOTICE: drop cascades to foreign table ft2
2014-07-10 21:01:31 +02:00
-- IMPORT FOREIGN SCHEMA
IMPORT FOREIGN SCHEMA s1 FROM SERVER s9 INTO public; -- ERROR
ERROR: foreign-data wrapper "foo" has no handler
IMPORT FOREIGN SCHEMA s1 LIMIT TO (t1) FROM SERVER s9 INTO public; --ERROR
ERROR: foreign-data wrapper "foo" has no handler
IMPORT FOREIGN SCHEMA s1 EXCEPT (t1) FROM SERVER s9 INTO public; -- ERROR
ERROR: foreign-data wrapper "foo" has no handler
IMPORT FOREIGN SCHEMA s1 EXCEPT (t1, t2) FROM SERVER s9 INTO public
OPTIONS (option1 'value1', option2 'value2'); -- ERROR
ERROR: foreign-data wrapper "foo" has no handler
2011-01-02 05:48:11 +01:00
-- DROP FOREIGN TABLE
DROP FOREIGN TABLE no_table; -- ERROR
ERROR: foreign table "no_table" does not exist
DROP FOREIGN TABLE IF EXISTS no_table;
NOTICE: foreign table "no_table" does not exist, skipping
DROP FOREIGN TABLE foreign_schema.foreign_table_1;
2015-12-11 22:39:09 +01:00
-- REASSIGN OWNED/DROP OWNED of foreign objects
REASSIGN OWNED BY regress_test_role TO regress_test_role2;
DROP OWNED BY regress_test_role2;
ERROR: cannot drop desired object(s) because other objects depend on them
DETAIL: user mapping for regress_test_role on server s5 depends on server s5
HINT: Use DROP ... CASCADE to drop the dependent objects too.
DROP OWNED BY regress_test_role2 CASCADE;
NOTICE: drop cascades to user mapping for regress_test_role on server s5
2008-12-19 17:25:19 +01:00
-- Cleanup
2011-01-02 05:48:11 +01:00
DROP SCHEMA foreign_schema CASCADE;
2008-12-19 17:25:19 +01:00
DROP ROLE regress_test_role; -- ERROR
ERROR: role "regress_test_role" cannot be dropped because some objects depend on it
2010-08-26 21:49:08 +02:00
DETAIL: privileges for server s4
privileges for foreign-data wrapper foo
2015-03-05 22:03:16 +01:00
owner of user mapping for regress_test_role on server s6
2009-03-09 16:04:21 +01:00
DROP SERVER t1 CASCADE;
2015-03-05 22:03:16 +01:00
NOTICE: drop cascades to user mapping for public on server t1
2008-12-19 17:25:19 +01:00
DROP USER MAPPING FOR regress_test_role SERVER s6;
2011-04-25 20:43:26 +02:00
-- This test causes some order dependent cascade detail output,
2012-05-15 21:19:04 +02:00
-- so switch to terse mode for it.
2011-04-25 20:43:26 +02:00
\set VERBOSITY terse
2008-12-19 17:25:19 +01:00
DROP FOREIGN DATA WRAPPER foo CASCADE;
2009-01-20 10:10:20 +01:00
NOTICE: drop cascades to 5 other objects
2011-04-25 20:43:26 +02:00
\set VERBOSITY default
2008-12-19 17:25:19 +01:00
DROP SERVER s8 CASCADE;
NOTICE: drop cascades to 2 other objects
2016-07-18 00:42:31 +02:00
DETAIL: drop cascades to user mapping for regress_foreign_data_user on server s8
2015-03-05 22:03:16 +01:00
drop cascades to user mapping for public on server s8
2008-12-19 17:25:19 +01:00
DROP ROLE regress_test_indirect;
DROP ROLE regress_test_role;
2016-07-18 00:42:31 +02:00
DROP ROLE regress_unprivileged_role; -- ERROR
ERROR: role "regress_unprivileged_role" cannot be dropped because some objects depend on it
2010-08-26 21:49:08 +02:00
DETAIL: privileges for foreign-data wrapper postgresql
2016-07-18 00:42:31 +02:00
REVOKE ALL ON FOREIGN DATA WRAPPER postgresql FROM regress_unprivileged_role;
DROP ROLE regress_unprivileged_role;
2008-12-19 17:25:19 +01:00
DROP ROLE regress_test_role2;
DROP FOREIGN DATA WRAPPER postgresql CASCADE;
DROP FOREIGN DATA WRAPPER dummy CASCADE;
2011-10-10 13:58:17 +02:00
NOTICE: drop cascades to server s0
2008-12-19 17:25:19 +01:00
\c
2016-07-18 00:42:31 +02:00
DROP ROLE regress_foreign_data_user;
2008-12-19 17:25:19 +01:00
-- At this point we should have no wrappers, no servers, and no mappings.
2011-02-19 06:06:18 +01:00
SELECT fdwname, fdwhandler, fdwvalidator, fdwoptions FROM pg_foreign_data_wrapper;
fdwname | fdwhandler | fdwvalidator | fdwoptions
---------+------------+--------------+------------
2008-12-19 17:25:19 +01:00
(0 rows)
SELECT srvname, srvoptions FROM pg_foreign_server;
srvname | srvoptions
---------+------------
(0 rows)
SELECT * FROM pg_user_mapping;
umuser | umserver | umoptions
--------+----------+-----------
(0 rows)
