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';
|
2008-12-19 17:25:19 +01:00
|
|
|
|
2016-07-18 00:42:31 +02:00
|
|
|
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;
|
2008-12-19 17:25:19 +01:00
|
|
|
|
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;
|
2008-12-19 17:25:19 +01:00
|
|
|
SELECT srvname, srvoptions FROM pg_foreign_server;
|
|
|
|
SELECT * FROM pg_user_mapping;
|
|
|
|
|
|
|
|
-- CREATE FOREIGN DATA WRAPPER
|
2009-02-24 11:06:36 +01:00
|
|
|
CREATE FOREIGN DATA WRAPPER foo VALIDATOR bar; -- ERROR
|
|
|
|
CREATE FOREIGN DATA WRAPPER foo;
|
2008-12-19 17:25:19 +01:00
|
|
|
\dew
|
|
|
|
|
2009-02-24 11:06:36 +01:00
|
|
|
CREATE FOREIGN DATA WRAPPER foo; -- duplicate
|
2008-12-19 17:25:19 +01:00
|
|
|
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+
|
|
|
|
|
|
|
|
DROP FOREIGN DATA WRAPPER foo;
|
2009-02-24 11:06:36 +01:00
|
|
|
CREATE FOREIGN DATA WRAPPER foo OPTIONS (testing '1', testing '2'); -- ERROR
|
|
|
|
CREATE FOREIGN DATA WRAPPER foo OPTIONS (testing '1', another '2');
|
2008-12-19 17:25:19 +01:00
|
|
|
\dew+
|
|
|
|
|
|
|
|
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
|
|
|
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+
|
|
|
|
|
2017-09-15 14:07:22 +02:00
|
|
|
-- HANDLER related checks
|
|
|
|
CREATE FUNCTION invalid_fdw_handler() RETURNS int LANGUAGE SQL AS 'SELECT 1;';
|
|
|
|
CREATE FOREIGN DATA WRAPPER test_fdw HANDLER invalid_fdw_handler; -- ERROR
|
|
|
|
CREATE FOREIGN DATA WRAPPER test_fdw HANDLER test_fdw_handler HANDLER invalid_fdw_handler; -- ERROR
|
|
|
|
CREATE FOREIGN DATA WRAPPER test_fdw HANDLER test_fdw_handler;
|
|
|
|
DROP FOREIGN DATA WRAPPER test_fdw;
|
|
|
|
|
2008-12-19 17:25:19 +01:00
|
|
|
-- ALTER FOREIGN DATA WRAPPER
|
2009-02-24 11:06:36 +01:00
|
|
|
ALTER FOREIGN DATA WRAPPER foo; -- ERROR
|
|
|
|
ALTER FOREIGN DATA WRAPPER foo VALIDATOR bar; -- ERROR
|
|
|
|
ALTER FOREIGN DATA WRAPPER foo NO VALIDATOR;
|
2008-12-19 17:25:19 +01:00
|
|
|
\dew+
|
|
|
|
|
|
|
|
ALTER FOREIGN DATA WRAPPER foo OPTIONS (a '1', b '2');
|
|
|
|
ALTER FOREIGN DATA WRAPPER foo OPTIONS (SET c '4'); -- ERROR
|
|
|
|
ALTER FOREIGN DATA WRAPPER foo OPTIONS (DROP c); -- ERROR
|
|
|
|
ALTER FOREIGN DATA WRAPPER foo OPTIONS (ADD x '1', DROP x);
|
|
|
|
\dew+
|
|
|
|
|
|
|
|
ALTER FOREIGN DATA WRAPPER foo OPTIONS (DROP a, SET b '3', ADD c '4');
|
|
|
|
\dew+
|
|
|
|
|
|
|
|
ALTER FOREIGN DATA WRAPPER foo OPTIONS (a '2');
|
|
|
|
ALTER FOREIGN DATA WRAPPER foo OPTIONS (b '4'); -- ERROR
|
|
|
|
\dew+
|
|
|
|
|
|
|
|
SET ROLE regress_test_role;
|
|
|
|
ALTER FOREIGN DATA WRAPPER foo OPTIONS (ADD d '5'); -- ERROR
|
|
|
|
SET ROLE regress_test_role_super;
|
|
|
|
ALTER FOREIGN DATA WRAPPER foo OPTIONS (ADD d '5');
|
|
|
|
\dew+
|
|
|
|
|
|
|
|
ALTER FOREIGN DATA WRAPPER foo OWNER TO regress_test_role; -- ERROR
|
|
|
|
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
|
|
|
|
RESET ROLE;
|
|
|
|
\dew+
|
|
|
|
|
2011-12-09 19:42:30 +01:00
|
|
|
ALTER FOREIGN DATA WRAPPER foo RENAME TO foo1;
|
|
|
|
\dew+
|
|
|
|
ALTER FOREIGN DATA WRAPPER foo1 RENAME TO foo;
|
|
|
|
|
2017-09-15 14:07:22 +02:00
|
|
|
-- HANDLER related checks
|
|
|
|
ALTER FOREIGN DATA WRAPPER foo HANDLER invalid_fdw_handler; -- ERROR
|
|
|
|
ALTER FOREIGN DATA WRAPPER foo HANDLER test_fdw_handler HANDLER anything; -- ERROR
|
|
|
|
ALTER FOREIGN DATA WRAPPER foo HANDLER test_fdw_handler;
|
|
|
|
DROP FUNCTION invalid_fdw_handler();
|
|
|
|
|
2008-12-19 17:25:19 +01:00
|
|
|
-- DROP FOREIGN DATA WRAPPER
|
|
|
|
DROP FOREIGN DATA WRAPPER nonexistent; -- ERROR
|
|
|
|
DROP FOREIGN DATA WRAPPER IF EXISTS nonexistent;
|
|
|
|
\dew+
|
|
|
|
|
|
|
|
DROP ROLE regress_test_role_super; -- ERROR
|
|
|
|
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+
|
|
|
|
|
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;
|
2017-03-20 21:40:45 +01:00
|
|
|
CREATE USER MAPPING FOR current_user SERVER s1; -- ERROR
|
|
|
|
CREATE USER MAPPING IF NOT EXISTS FOR current_user SERVER s1; -- NOTICE
|
2008-12-19 17:25:19 +01:00
|
|
|
\dew+
|
|
|
|
\des+
|
|
|
|
\deu+
|
|
|
|
DROP FOREIGN DATA WRAPPER foo; -- ERROR
|
|
|
|
SET ROLE regress_test_role;
|
|
|
|
DROP FOREIGN DATA WRAPPER foo CASCADE; -- ERROR
|
|
|
|
RESET ROLE;
|
|
|
|
DROP FOREIGN DATA WRAPPER foo CASCADE;
|
|
|
|
\dew+
|
|
|
|
\des+
|
|
|
|
\deu+
|
|
|
|
|
|
|
|
-- exercise CREATE SERVER
|
|
|
|
CREATE SERVER s1 FOREIGN DATA WRAPPER foo; -- ERROR
|
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
|
2017-03-20 21:40:45 +01:00
|
|
|
CREATE SERVER IF NOT EXISTS s1 FOREIGN DATA WRAPPER foo; -- No ERROR, just NOTICE
|
2008-12-19 17:25:19 +01:00
|
|
|
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
|
|
|
|
CREATE SERVER s8 FOREIGN DATA WRAPPER postgresql OPTIONS (host 'localhost', dbname 's8db');
|
|
|
|
\des+
|
|
|
|
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
|
|
|
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+
|
|
|
|
|
|
|
|
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
|
|
|
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+
|
|
|
|
RESET ROLE;
|
|
|
|
REVOKE regress_test_indirect FROM regress_test_role;
|
|
|
|
|
|
|
|
-- ALTER SERVER
|
|
|
|
ALTER SERVER s0; -- ERROR
|
|
|
|
ALTER SERVER s0 OPTIONS (a '1'); -- ERROR
|
|
|
|
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+
|
|
|
|
SET ROLE regress_test_role;
|
|
|
|
ALTER SERVER s1 VERSION '1.1'; -- ERROR
|
|
|
|
ALTER SERVER s1 OWNER TO regress_test_role; -- ERROR
|
|
|
|
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
|
|
|
|
RESET ROLE;
|
|
|
|
ALTER SERVER s8 OPTIONS (foo '1'); -- ERROR option validation
|
|
|
|
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
|
|
|
|
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
|
|
|
|
\des+
|
|
|
|
|
2011-12-09 19:42:30 +01:00
|
|
|
ALTER SERVER s8 RENAME to s8new;
|
|
|
|
\des+
|
|
|
|
ALTER SERVER s8new RENAME to s8;
|
|
|
|
|
2008-12-19 17:25:19 +01:00
|
|
|
-- DROP SERVER
|
|
|
|
DROP SERVER nonexistent; -- ERROR
|
|
|
|
DROP SERVER IF EXISTS nonexistent;
|
|
|
|
\des
|
|
|
|
SET ROLE regress_test_role;
|
|
|
|
DROP SERVER s2; -- ERROR
|
|
|
|
DROP SERVER s1;
|
|
|
|
RESET ROLE;
|
|
|
|
\des
|
|
|
|
ALTER SERVER s2 OWNER TO regress_test_role;
|
|
|
|
SET ROLE regress_test_role;
|
|
|
|
DROP SERVER s2;
|
|
|
|
RESET ROLE;
|
|
|
|
\des
|
|
|
|
CREATE USER MAPPING FOR current_user SERVER s3;
|
|
|
|
\deu
|
|
|
|
DROP SERVER s3; -- ERROR
|
|
|
|
DROP SERVER s3 CASCADE;
|
|
|
|
\des
|
|
|
|
\deu
|
|
|
|
|
|
|
|
-- CREATE USER MAPPING
|
2009-10-15 01:36:43 +02:00
|
|
|
CREATE USER MAPPING FOR regress_test_missing_role SERVER s1; -- ERROR
|
2008-12-19 17:25:19 +01:00
|
|
|
CREATE USER MAPPING FOR current_user SERVER s1; -- ERROR
|
|
|
|
CREATE USER MAPPING FOR current_user SERVER s4;
|
|
|
|
CREATE USER MAPPING FOR user SERVER s4; -- ERROR duplicate
|
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
|
|
|
|
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
|
|
|
|
CREATE USER MAPPING FOR public SERVER s8; -- ERROR
|
|
|
|
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
|
|
|
|
|
|
|
|
-- 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
|
2008-12-19 17:25:19 +01:00
|
|
|
ALTER USER MAPPING FOR user SERVER ss4 OPTIONS (gotcha 'true'); -- ERROR
|
|
|
|
ALTER USER MAPPING FOR public SERVER s5 OPTIONS (gotcha 'true'); -- ERROR
|
|
|
|
ALTER USER MAPPING FOR current_user SERVER s8 OPTIONS (username 'test'); -- ERROR
|
|
|
|
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
|
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+
|
|
|
|
|
|
|
|
-- DROP USER MAPPING
|
2009-10-15 01:36:43 +02:00
|
|
|
DROP USER MAPPING FOR regress_test_missing_role SERVER s4; -- ERROR
|
2008-12-19 17:25:19 +01:00
|
|
|
DROP USER MAPPING FOR user SERVER ss4;
|
|
|
|
DROP USER MAPPING FOR public SERVER s7; -- ERROR
|
2009-10-15 01:36:43 +02:00
|
|
|
DROP USER MAPPING IF EXISTS FOR regress_test_missing_role SERVER s4;
|
2008-12-19 17:25:19 +01:00
|
|
|
DROP USER MAPPING IF EXISTS FOR user SERVER ss4;
|
|
|
|
DROP USER MAPPING IF EXISTS FOR public SERVER s7;
|
|
|
|
CREATE USER MAPPING FOR public SERVER s8;
|
|
|
|
SET ROLE regress_test_role;
|
|
|
|
DROP USER MAPPING FOR public SERVER s8; -- ERROR
|
|
|
|
RESET ROLE;
|
|
|
|
DROP SERVER s7;
|
|
|
|
\deu
|
|
|
|
|
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
|
|
|
|
CREATE FOREIGN TABLE ft1 () SERVER no_server; -- ERROR
|
|
|
|
CREATE FOREIGN TABLE ft1 (
|
2014-12-17 23:00:53 +01:00
|
|
|
c1 integer OPTIONS ("param 1" 'val1') PRIMARY KEY,
|
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
|
|
|
|
CREATE TABLE ref_table (id integer PRIMARY KEY);
|
|
|
|
CREATE FOREIGN TABLE ft1 (
|
|
|
|
c1 integer OPTIONS ("param 1" 'val1') REFERENCES ref_table (id),
|
|
|
|
c2 text OPTIONS (param2 'val2', param3 'val3'),
|
|
|
|
c3 date
|
|
|
|
) SERVER s0 OPTIONS (delimiter ',', quote '"', "be quoted" 'value'); -- ERROR
|
|
|
|
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
|
|
|
|
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
|
|
|
|
\det+
|
|
|
|
CREATE INDEX id_ft1_c2 ON ft1 (c2); -- ERROR
|
2011-02-19 06:06:18 +01:00
|
|
|
SELECT * FROM ft1; -- ERROR
|
|
|
|
EXPLAIN SELECT * FROM ft1; -- ERROR
|
2011-01-02 05:48:11 +01:00
|
|
|
|
2018-05-14 19:09:32 +02:00
|
|
|
CREATE TABLE lt1 (a INT) PARTITION BY RANGE (a);
|
|
|
|
CREATE FOREIGN TABLE ft_part1
|
|
|
|
PARTITION OF lt1 FOR VALUES FROM (0) TO (1000) SERVER s0;
|
2019-06-27 00:38:51 +02:00
|
|
|
CREATE INDEX ON lt1 (a); -- skips partition
|
|
|
|
CREATE UNIQUE INDEX ON lt1 (a); -- ERROR
|
|
|
|
ALTER TABLE lt1 ADD PRIMARY KEY (a); -- ERROR
|
2018-05-14 19:09:32 +02:00
|
|
|
DROP TABLE lt1;
|
|
|
|
|
2019-06-27 00:38:51 +02:00
|
|
|
CREATE TABLE lt1 (a INT) PARTITION BY RANGE (a);
|
|
|
|
CREATE INDEX ON lt1 (a);
|
|
|
|
CREATE FOREIGN TABLE ft_part1
|
|
|
|
PARTITION OF lt1 FOR VALUES FROM (0) TO (1000) SERVER s0;
|
|
|
|
CREATE FOREIGN TABLE ft_part2 (a INT) SERVER s0;
|
|
|
|
ALTER TABLE lt1 ATTACH PARTITION ft_part2 FOR VALUES FROM (1000) TO (2000);
|
|
|
|
DROP FOREIGN TABLE ft_part1, ft_part2;
|
|
|
|
CREATE UNIQUE INDEX ON lt1 (a);
|
|
|
|
ALTER TABLE lt1 ADD PRIMARY KEY (a);
|
|
|
|
CREATE FOREIGN TABLE ft_part1
|
|
|
|
PARTITION OF lt1 FOR VALUES FROM (0) TO (1000) SERVER s0; -- ERROR
|
|
|
|
CREATE FOREIGN TABLE ft_part2 (a INT NOT NULL) SERVER s0;
|
|
|
|
ALTER TABLE lt1 ATTACH PARTITION ft_part2
|
|
|
|
FOR VALUES FROM (1000) TO (2000); -- ERROR
|
|
|
|
DROP TABLE lt1;
|
|
|
|
DROP FOREIGN TABLE ft_part2;
|
|
|
|
|
|
|
|
CREATE TABLE lt1 (a INT) PARTITION BY RANGE (a);
|
|
|
|
CREATE INDEX ON lt1 (a);
|
|
|
|
CREATE TABLE lt1_part1
|
|
|
|
PARTITION OF lt1 FOR VALUES FROM (0) TO (1000)
|
|
|
|
PARTITION BY RANGE (a);
|
|
|
|
CREATE FOREIGN TABLE ft_part_1_1
|
|
|
|
PARTITION OF lt1_part1 FOR VALUES FROM (0) TO (100) SERVER s0;
|
|
|
|
CREATE FOREIGN TABLE ft_part_1_2 (a INT) SERVER s0;
|
|
|
|
ALTER TABLE lt1_part1 ATTACH PARTITION ft_part_1_2 FOR VALUES FROM (100) TO (200);
|
|
|
|
CREATE UNIQUE INDEX ON lt1 (a);
|
|
|
|
ALTER TABLE lt1 ADD PRIMARY KEY (a);
|
|
|
|
DROP FOREIGN TABLE ft_part_1_1, ft_part_1_2;
|
|
|
|
CREATE UNIQUE INDEX ON lt1 (a);
|
|
|
|
ALTER TABLE lt1 ADD PRIMARY KEY (a);
|
|
|
|
CREATE FOREIGN TABLE ft_part_1_1
|
|
|
|
PARTITION OF lt1_part1 FOR VALUES FROM (0) TO (100) SERVER s0;
|
|
|
|
CREATE FOREIGN TABLE ft_part_1_2 (a INT NOT NULL) SERVER s0;
|
|
|
|
ALTER TABLE lt1_part1 ATTACH PARTITION ft_part_1_2 FOR VALUES FROM (100) TO (200);
|
|
|
|
DROP TABLE lt1;
|
|
|
|
DROP FOREIGN TABLE ft_part_1_2;
|
|
|
|
|
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');
|
2011-01-02 05:48:11 +01:00
|
|
|
|
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
|
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
|
|
|
|
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
|
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
|
|
|
|
DROP TABLE use_ft1_column_type;
|
2014-12-17 23:00:53 +01:00
|
|
|
ALTER FOREIGN TABLE ft1 ADD PRIMARY KEY (c7); -- ERROR
|
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
|
|
|
|
ALTER FOREIGN TABLE ft1 DROP CONSTRAINT ft1_c9_check;
|
2011-01-02 05:48:11 +01:00
|
|
|
ALTER FOREIGN TABLE ft1 DROP CONSTRAINT no_const; -- ERROR
|
|
|
|
ALTER FOREIGN TABLE ft1 DROP CONSTRAINT IF EXISTS no_const;
|
|
|
|
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
|
|
|
|
ALTER FOREIGN TABLE ft1 DROP COLUMN IF EXISTS no_column;
|
|
|
|
ALTER FOREIGN TABLE ft1 DROP COLUMN c9;
|
|
|
|
ALTER FOREIGN TABLE ft1 SET SCHEMA foreign_schema;
|
|
|
|
ALTER FOREIGN TABLE ft1 SET TABLESPACE ts; -- ERROR
|
|
|
|
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
|
|
|
|
|
2012-01-24 00:25:04 +01:00
|
|
|
-- alter noexisting table
|
|
|
|
ALTER FOREIGN TABLE IF EXISTS doesnt_exist_ft1 ADD COLUMN c4 integer;
|
|
|
|
ALTER FOREIGN TABLE IF EXISTS doesnt_exist_ft1 ADD COLUMN c6 integer;
|
|
|
|
ALTER FOREIGN TABLE IF EXISTS doesnt_exist_ft1 ADD COLUMN c7 integer NOT NULL;
|
|
|
|
ALTER FOREIGN TABLE IF EXISTS doesnt_exist_ft1 ADD COLUMN c8 integer;
|
|
|
|
ALTER FOREIGN TABLE IF EXISTS doesnt_exist_ft1 ADD COLUMN c9 integer;
|
|
|
|
ALTER FOREIGN TABLE IF EXISTS doesnt_exist_ft1 ADD COLUMN c10 integer OPTIONS (p1 'v1');
|
|
|
|
|
|
|
|
ALTER FOREIGN TABLE IF EXISTS doesnt_exist_ft1 ALTER COLUMN c6 SET NOT NULL;
|
|
|
|
ALTER FOREIGN TABLE IF EXISTS doesnt_exist_ft1 ALTER COLUMN c7 DROP NOT NULL;
|
|
|
|
ALTER FOREIGN TABLE IF EXISTS doesnt_exist_ft1 ALTER COLUMN c8 TYPE char(10);
|
|
|
|
ALTER FOREIGN TABLE IF EXISTS doesnt_exist_ft1 ALTER COLUMN c8 SET DATA TYPE text;
|
|
|
|
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');
|
|
|
|
ALTER FOREIGN TABLE IF EXISTS doesnt_exist_ft1 ALTER COLUMN c8 OPTIONS (SET p2 'V2', DROP p1);
|
|
|
|
|
|
|
|
ALTER FOREIGN TABLE IF EXISTS doesnt_exist_ft1 DROP CONSTRAINT IF EXISTS no_const;
|
|
|
|
ALTER FOREIGN TABLE IF EXISTS doesnt_exist_ft1 DROP CONSTRAINT ft1_c1_check;
|
|
|
|
ALTER FOREIGN TABLE IF EXISTS doesnt_exist_ft1 OWNER TO regress_test_role;
|
|
|
|
ALTER FOREIGN TABLE IF EXISTS doesnt_exist_ft1 OPTIONS (DROP delimiter, SET quote '~', ADD escape '@');
|
|
|
|
ALTER FOREIGN TABLE IF EXISTS doesnt_exist_ft1 DROP COLUMN IF EXISTS no_column;
|
|
|
|
ALTER FOREIGN TABLE IF EXISTS doesnt_exist_ft1 DROP COLUMN c9;
|
|
|
|
ALTER FOREIGN TABLE IF EXISTS doesnt_exist_ft1 SET SCHEMA foreign_schema;
|
|
|
|
ALTER FOREIGN TABLE IF EXISTS doesnt_exist_ft1 RENAME c1 TO foreign_column_1;
|
|
|
|
ALTER FOREIGN TABLE IF EXISTS doesnt_exist_ft1 RENAME TO foreign_table_1;
|
|
|
|
|
2008-12-19 17:25:19 +01:00
|
|
|
-- Information schema
|
|
|
|
|
|
|
|
SELECT * FROM information_schema.foreign_data_wrappers ORDER BY 1, 2;
|
|
|
|
SELECT * FROM information_schema.foreign_data_wrapper_options ORDER BY 1, 2, 3;
|
|
|
|
SELECT * FROM information_schema.foreign_servers ORDER BY 1, 2;
|
|
|
|
SELECT * FROM information_schema.foreign_server_options ORDER BY 1, 2, 3;
|
2009-01-11 10:41:45 +01:00
|
|
|
SELECT * FROM information_schema.user_mappings ORDER BY lower(authorization_identifier), 2, 3;
|
|
|
|
SELECT * FROM information_schema.user_mapping_options ORDER BY lower(authorization_identifier), 2, 3, 4;
|
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;
|
|
|
|
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;
|
2011-01-02 05:48:11 +01:00
|
|
|
SELECT * FROM information_schema.foreign_tables ORDER BY 1, 2, 3;
|
|
|
|
SELECT * FROM information_schema.foreign_table_options ORDER BY 1, 2, 3, 4;
|
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;
|
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;
|
|
|
|
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;
|
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;
|
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');
|
|
|
|
SELECT has_foreign_data_wrapper_privilege('regress_test_role', 'foo', 'USAGE');
|
|
|
|
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');
|
|
|
|
SELECT has_foreign_data_wrapper_privilege(
|
|
|
|
(SELECT oid FROM pg_foreign_data_wrapper WHERE fdwname='foo'), 'USAGE');
|
|
|
|
SELECT has_foreign_data_wrapper_privilege(
|
|
|
|
(SELECT oid FROM pg_roles WHERE rolname='regress_test_role'), 'foo', 'USAGE');
|
|
|
|
SELECT has_foreign_data_wrapper_privilege('foo', 'USAGE');
|
|
|
|
GRANT USAGE ON FOREIGN DATA WRAPPER foo TO regress_test_role;
|
|
|
|
SELECT has_foreign_data_wrapper_privilege('regress_test_role', 'foo', 'USAGE');
|
|
|
|
|
|
|
|
-- has_server_privilege
|
|
|
|
SELECT has_server_privilege('regress_test_role',
|
|
|
|
(SELECT oid FROM pg_foreign_server WHERE srvname='s8'), 'USAGE');
|
|
|
|
SELECT has_server_privilege('regress_test_role', 's8', 'USAGE');
|
|
|
|
SELECT has_server_privilege(
|
|
|
|
(SELECT oid FROM pg_roles WHERE rolname='regress_test_role'),
|
|
|
|
(SELECT oid FROM pg_foreign_server WHERE srvname='s8'), 'USAGE');
|
|
|
|
SELECT has_server_privilege(
|
|
|
|
(SELECT oid FROM pg_foreign_server WHERE srvname='s8'), 'USAGE');
|
|
|
|
SELECT has_server_privilege(
|
|
|
|
(SELECT oid FROM pg_roles WHERE rolname='regress_test_role'), 's8', 'USAGE');
|
|
|
|
SELECT has_server_privilege('s8', 'USAGE');
|
|
|
|
GRANT USAGE ON FOREIGN SERVER s8 TO regress_test_role;
|
|
|
|
SELECT has_server_privilege('regress_test_role', 's8', 'USAGE');
|
|
|
|
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;
|
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
|
|
|
ALTER FOREIGN DATA WRAPPER foo OPTIONS (gotcha 'true'); -- ERROR
|
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
|
|
|
DROP FOREIGN DATA WRAPPER foo; -- ERROR
|
|
|
|
GRANT USAGE ON FOREIGN DATA WRAPPER foo TO regress_test_role; -- ERROR
|
|
|
|
CREATE SERVER s9 FOREIGN DATA WRAPPER foo; -- ERROR
|
|
|
|
ALTER SERVER s4 VERSION '0.5'; -- ERROR
|
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
|
|
|
DROP SERVER s4; -- ERROR
|
|
|
|
GRANT USAGE ON FOREIGN SERVER s4 TO regress_test_role; -- ERROR
|
|
|
|
CREATE USER MAPPING FOR public SERVER s4; -- ERROR
|
|
|
|
ALTER USER MAPPING FOR regress_test_role SERVER s6 OPTIONS (gotcha 'true'); -- ERROR
|
|
|
|
DROP USER MAPPING FOR regress_test_role SERVER s6; -- ERROR
|
|
|
|
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
|
|
|
ALTER FOREIGN DATA WRAPPER foo OPTIONS (gotcha 'true'); -- ERROR
|
|
|
|
DROP FOREIGN DATA WRAPPER foo; -- ERROR
|
|
|
|
GRANT USAGE ON FOREIGN DATA WRAPPER postgresql TO regress_test_role; -- WARNING
|
|
|
|
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
|
|
|
|
DROP SERVER s6; -- ERROR
|
|
|
|
GRANT USAGE ON FOREIGN SERVER s6 TO regress_test_role; -- ERROR
|
|
|
|
GRANT USAGE ON FOREIGN SERVER s9 TO regress_test_role;
|
|
|
|
CREATE USER MAPPING FOR public SERVER s6; -- ERROR
|
|
|
|
CREATE USER MAPPING FOR public SERVER s9;
|
|
|
|
ALTER USER MAPPING FOR regress_test_role SERVER s6 OPTIONS (gotcha 'true'); -- ERROR
|
|
|
|
DROP USER MAPPING FOR regress_test_role SERVER s6; -- ERROR
|
|
|
|
RESET ROLE;
|
|
|
|
|
2016-07-18 00:42:31 +02:00
|
|
|
REVOKE USAGE ON FOREIGN DATA WRAPPER foo FROM regress_unprivileged_role; -- ERROR
|
|
|
|
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
|
|
|
|
CREATE SERVER s10 FOREIGN DATA WRAPPER foo; -- ERROR
|
|
|
|
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;
|
|
|
|
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
|
|
|
|
GRANT USAGE ON FOREIGN SERVER s9 TO regress_test_role; -- WARNING
|
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
|
2017-05-08 16:24:24 +02:00
|
|
|
|
|
|
|
-- Check visibility of user mapping data
|
|
|
|
SET ROLE regress_test_role;
|
|
|
|
CREATE SERVER s10 FOREIGN DATA WRAPPER foo;
|
|
|
|
CREATE USER MAPPING FOR public SERVER s10 OPTIONS (user 'secret');
|
2017-08-07 16:09:28 +02:00
|
|
|
CREATE USER MAPPING FOR regress_unprivileged_role SERVER s10 OPTIONS (user 'secret');
|
|
|
|
-- owner of server can see some option fields
|
2017-05-08 16:24:24 +02:00
|
|
|
\deu+
|
|
|
|
RESET ROLE;
|
2017-08-07 16:09:28 +02:00
|
|
|
-- superuser can see all option fields
|
2017-05-08 16:24:24 +02:00
|
|
|
\deu+
|
2017-08-07 16:09:28 +02:00
|
|
|
-- unprivileged user cannot see any option field
|
2017-05-08 16:24:24 +02:00
|
|
|
SET ROLE regress_unprivileged_role;
|
|
|
|
\deu+
|
2008-12-19 17:25:19 +01:00
|
|
|
RESET ROLE;
|
2017-05-08 16:24:24 +02:00
|
|
|
DROP SERVER s10 CASCADE;
|
2008-12-19 17:25:19 +01:00
|
|
|
|
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();
|
|
|
|
|
2017-05-10 05:34:02 +02:00
|
|
|
CREATE TRIGGER trigtest_after_stmt_tt AFTER INSERT OR UPDATE OR DELETE -- ERROR
|
|
|
|
ON foreign_schema.foreign_table_1
|
|
|
|
REFERENCING NEW TABLE AS new_table
|
|
|
|
FOR EACH STATEMENT
|
|
|
|
EXECUTE PROCEDURE dummy_trigger();
|
|
|
|
|
2014-03-23 07:16:34 +01:00
|
|
|
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();
|
|
|
|
|
|
|
|
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
|
Clean up duplicate table and function names in regression tests.
Many of the objects we create during the regression tests are put in the
public schema, so that using the same names in different regression tests
creates a hazard of test failures if any two such scripts run concurrently.
This patch cleans up a bunch of latent hazards of that sort, as well as two
live hazards.
The current situation in this regard is far worse than it was a year or two
back, because practically all of the partitioning-related test cases have
reused table names with enthusiasm. I despaired of cleaning up that mess
within the five most-affected tests (create_table, alter_table, insert,
update, inherit); fortunately those don't run concurrently.
Other than partitioning problems, most of the issues boil down to using
names like "foo", "bar", "tmp", etc, without thought for the fact that
other test scripts might use similar names concurrently. I've made an
effort to make all such names more specific.
One of the live hazards was that commit 7421f4b8 caused with.sql to
create a table named "test", conflicting with a similarly-named table
in alter_table.sql; this was exposed in the buildfarm recently.
The other one was that join.sql and transactions.sql both create tables
named "foo" and "bar"; but join.sql's uses of those names date back
only to December or so.
Since commit 7421f4b8 was back-patched to v10, back-patch a minimal
fix for that problem. The rest of this is just future-proofing.
Discussion: https://postgr.es/m/4627.1521070268@sss.pgh.pa.us
2018-03-15 22:08:51 +01:00
|
|
|
CREATE TABLE fd_pt1 (
|
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
|
|
|
c1 integer NOT NULL,
|
|
|
|
c2 text,
|
|
|
|
c3 date
|
|
|
|
);
|
Clean up duplicate table and function names in regression tests.
Many of the objects we create during the regression tests are put in the
public schema, so that using the same names in different regression tests
creates a hazard of test failures if any two such scripts run concurrently.
This patch cleans up a bunch of latent hazards of that sort, as well as two
live hazards.
The current situation in this regard is far worse than it was a year or two
back, because practically all of the partitioning-related test cases have
reused table names with enthusiasm. I despaired of cleaning up that mess
within the five most-affected tests (create_table, alter_table, insert,
update, inherit); fortunately those don't run concurrently.
Other than partitioning problems, most of the issues boil down to using
names like "foo", "bar", "tmp", etc, without thought for the fact that
other test scripts might use similar names concurrently. I've made an
effort to make all such names more specific.
One of the live hazards was that commit 7421f4b8 caused with.sql to
create a table named "test", conflicting with a similarly-named table
in alter_table.sql; this was exposed in the buildfarm recently.
The other one was that join.sql and transactions.sql both create tables
named "foo" and "bar"; but join.sql's uses of those names date back
only to December or so.
Since commit 7421f4b8 was back-patched to v10, back-patch a minimal
fix for that problem. The rest of this is just future-proofing.
Discussion: https://postgr.es/m/4627.1521070268@sss.pgh.pa.us
2018-03-15 22:08:51 +01:00
|
|
|
CREATE FOREIGN TABLE ft2 () INHERITS (fd_pt1)
|
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 OPTIONS (delimiter ',', quote '"', "be quoted" 'value');
|
Clean up duplicate table and function names in regression tests.
Many of the objects we create during the regression tests are put in the
public schema, so that using the same names in different regression tests
creates a hazard of test failures if any two such scripts run concurrently.
This patch cleans up a bunch of latent hazards of that sort, as well as two
live hazards.
The current situation in this regard is far worse than it was a year or two
back, because practically all of the partitioning-related test cases have
reused table names with enthusiasm. I despaired of cleaning up that mess
within the five most-affected tests (create_table, alter_table, insert,
update, inherit); fortunately those don't run concurrently.
Other than partitioning problems, most of the issues boil down to using
names like "foo", "bar", "tmp", etc, without thought for the fact that
other test scripts might use similar names concurrently. I've made an
effort to make all such names more specific.
One of the live hazards was that commit 7421f4b8 caused with.sql to
create a table named "test", conflicting with a similarly-named table
in alter_table.sql; this was exposed in the buildfarm recently.
The other one was that join.sql and transactions.sql both create tables
named "foo" and "bar"; but join.sql's uses of those names date back
only to December or so.
Since commit 7421f4b8 was back-patched to v10, back-patch a minimal
fix for that problem. The rest of this is just future-proofing.
Discussion: https://postgr.es/m/4627.1521070268@sss.pgh.pa.us
2018-03-15 22:08:51 +01:00
|
|
|
\d+ fd_pt1
|
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
|
|
|
\d+ ft2
|
|
|
|
DROP FOREIGN TABLE ft2;
|
Clean up duplicate table and function names in regression tests.
Many of the objects we create during the regression tests are put in the
public schema, so that using the same names in different regression tests
creates a hazard of test failures if any two such scripts run concurrently.
This patch cleans up a bunch of latent hazards of that sort, as well as two
live hazards.
The current situation in this regard is far worse than it was a year or two
back, because practically all of the partitioning-related test cases have
reused table names with enthusiasm. I despaired of cleaning up that mess
within the five most-affected tests (create_table, alter_table, insert,
update, inherit); fortunately those don't run concurrently.
Other than partitioning problems, most of the issues boil down to using
names like "foo", "bar", "tmp", etc, without thought for the fact that
other test scripts might use similar names concurrently. I've made an
effort to make all such names more specific.
One of the live hazards was that commit 7421f4b8 caused with.sql to
create a table named "test", conflicting with a similarly-named table
in alter_table.sql; this was exposed in the buildfarm recently.
The other one was that join.sql and transactions.sql both create tables
named "foo" and "bar"; but join.sql's uses of those names date back
only to December or so.
Since commit 7421f4b8 was back-patched to v10, back-patch a minimal
fix for that problem. The rest of this is just future-proofing.
Discussion: https://postgr.es/m/4627.1521070268@sss.pgh.pa.us
2018-03-15 22:08:51 +01:00
|
|
|
\d+ fd_pt1
|
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
|
Clean up duplicate table and function names in regression tests.
Many of the objects we create during the regression tests are put in the
public schema, so that using the same names in different regression tests
creates a hazard of test failures if any two such scripts run concurrently.
This patch cleans up a bunch of latent hazards of that sort, as well as two
live hazards.
The current situation in this regard is far worse than it was a year or two
back, because practically all of the partitioning-related test cases have
reused table names with enthusiasm. I despaired of cleaning up that mess
within the five most-affected tests (create_table, alter_table, insert,
update, inherit); fortunately those don't run concurrently.
Other than partitioning problems, most of the issues boil down to using
names like "foo", "bar", "tmp", etc, without thought for the fact that
other test scripts might use similar names concurrently. I've made an
effort to make all such names more specific.
One of the live hazards was that commit 7421f4b8 caused with.sql to
create a table named "test", conflicting with a similarly-named table
in alter_table.sql; this was exposed in the buildfarm recently.
The other one was that join.sql and transactions.sql both create tables
named "foo" and "bar"; but join.sql's uses of those names date back
only to December or so.
Since commit 7421f4b8 was back-patched to v10, back-patch a minimal
fix for that problem. The rest of this is just future-proofing.
Discussion: https://postgr.es/m/4627.1521070268@sss.pgh.pa.us
2018-03-15 22:08:51 +01:00
|
|
|
ALTER FOREIGN TABLE ft2 INHERIT fd_pt1;
|
|
|
|
\d+ fd_pt1
|
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
|
|
|
\d+ ft2
|
|
|
|
CREATE TABLE ct3() INHERITS(ft2);
|
|
|
|
CREATE FOREIGN TABLE ft3 (
|
|
|
|
c1 integer NOT NULL,
|
|
|
|
c2 text,
|
|
|
|
c3 date
|
|
|
|
) INHERITS(ft2)
|
|
|
|
SERVER s0;
|
|
|
|
\d+ ft2
|
|
|
|
\d+ ct3
|
|
|
|
\d+ ft3
|
|
|
|
|
|
|
|
-- add attributes recursively
|
Clean up duplicate table and function names in regression tests.
Many of the objects we create during the regression tests are put in the
public schema, so that using the same names in different regression tests
creates a hazard of test failures if any two such scripts run concurrently.
This patch cleans up a bunch of latent hazards of that sort, as well as two
live hazards.
The current situation in this regard is far worse than it was a year or two
back, because practically all of the partitioning-related test cases have
reused table names with enthusiasm. I despaired of cleaning up that mess
within the five most-affected tests (create_table, alter_table, insert,
update, inherit); fortunately those don't run concurrently.
Other than partitioning problems, most of the issues boil down to using
names like "foo", "bar", "tmp", etc, without thought for the fact that
other test scripts might use similar names concurrently. I've made an
effort to make all such names more specific.
One of the live hazards was that commit 7421f4b8 caused with.sql to
create a table named "test", conflicting with a similarly-named table
in alter_table.sql; this was exposed in the buildfarm recently.
The other one was that join.sql and transactions.sql both create tables
named "foo" and "bar"; but join.sql's uses of those names date back
only to December or so.
Since commit 7421f4b8 was back-patched to v10, back-patch a minimal
fix for that problem. The rest of this is just future-proofing.
Discussion: https://postgr.es/m/4627.1521070268@sss.pgh.pa.us
2018-03-15 22:08:51 +01:00
|
|
|
ALTER TABLE fd_pt1 ADD COLUMN c4 integer;
|
|
|
|
ALTER TABLE fd_pt1 ADD COLUMN c5 integer DEFAULT 0;
|
|
|
|
ALTER TABLE fd_pt1 ADD COLUMN c6 integer;
|
|
|
|
ALTER TABLE fd_pt1 ADD COLUMN c7 integer NOT NULL;
|
|
|
|
ALTER TABLE fd_pt1 ADD COLUMN c8 integer;
|
|
|
|
\d+ fd_pt1
|
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
|
|
|
\d+ ft2
|
|
|
|
\d+ ct3
|
|
|
|
\d+ ft3
|
|
|
|
|
|
|
|
-- alter attributes recursively
|
Clean up duplicate table and function names in regression tests.
Many of the objects we create during the regression tests are put in the
public schema, so that using the same names in different regression tests
creates a hazard of test failures if any two such scripts run concurrently.
This patch cleans up a bunch of latent hazards of that sort, as well as two
live hazards.
The current situation in this regard is far worse than it was a year or two
back, because practically all of the partitioning-related test cases have
reused table names with enthusiasm. I despaired of cleaning up that mess
within the five most-affected tests (create_table, alter_table, insert,
update, inherit); fortunately those don't run concurrently.
Other than partitioning problems, most of the issues boil down to using
names like "foo", "bar", "tmp", etc, without thought for the fact that
other test scripts might use similar names concurrently. I've made an
effort to make all such names more specific.
One of the live hazards was that commit 7421f4b8 caused with.sql to
create a table named "test", conflicting with a similarly-named table
in alter_table.sql; this was exposed in the buildfarm recently.
The other one was that join.sql and transactions.sql both create tables
named "foo" and "bar"; but join.sql's uses of those names date back
only to December or so.
Since commit 7421f4b8 was back-patched to v10, back-patch a minimal
fix for that problem. The rest of this is just future-proofing.
Discussion: https://postgr.es/m/4627.1521070268@sss.pgh.pa.us
2018-03-15 22:08:51 +01:00
|
|
|
ALTER TABLE fd_pt1 ALTER COLUMN c4 SET DEFAULT 0;
|
|
|
|
ALTER TABLE fd_pt1 ALTER COLUMN c5 DROP DEFAULT;
|
|
|
|
ALTER TABLE fd_pt1 ALTER COLUMN c6 SET NOT NULL;
|
|
|
|
ALTER TABLE fd_pt1 ALTER COLUMN c7 DROP NOT NULL;
|
|
|
|
ALTER TABLE fd_pt1 ALTER COLUMN c8 TYPE char(10) USING '0'; -- ERROR
|
|
|
|
ALTER TABLE fd_pt1 ALTER COLUMN c8 TYPE char(10);
|
|
|
|
ALTER TABLE fd_pt1 ALTER COLUMN c8 SET DATA TYPE text;
|
|
|
|
ALTER TABLE fd_pt1 ALTER COLUMN c1 SET STATISTICS 10000;
|
|
|
|
ALTER TABLE fd_pt1 ALTER COLUMN c1 SET (n_distinct = 100);
|
|
|
|
ALTER TABLE fd_pt1 ALTER COLUMN c8 SET STATISTICS -1;
|
|
|
|
ALTER TABLE fd_pt1 ALTER COLUMN c8 SET STORAGE EXTERNAL;
|
|
|
|
\d+ fd_pt1
|
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
|
|
|
\d+ ft2
|
|
|
|
|
|
|
|
-- drop attributes recursively
|
Clean up duplicate table and function names in regression tests.
Many of the objects we create during the regression tests are put in the
public schema, so that using the same names in different regression tests
creates a hazard of test failures if any two such scripts run concurrently.
This patch cleans up a bunch of latent hazards of that sort, as well as two
live hazards.
The current situation in this regard is far worse than it was a year or two
back, because practically all of the partitioning-related test cases have
reused table names with enthusiasm. I despaired of cleaning up that mess
within the five most-affected tests (create_table, alter_table, insert,
update, inherit); fortunately those don't run concurrently.
Other than partitioning problems, most of the issues boil down to using
names like "foo", "bar", "tmp", etc, without thought for the fact that
other test scripts might use similar names concurrently. I've made an
effort to make all such names more specific.
One of the live hazards was that commit 7421f4b8 caused with.sql to
create a table named "test", conflicting with a similarly-named table
in alter_table.sql; this was exposed in the buildfarm recently.
The other one was that join.sql and transactions.sql both create tables
named "foo" and "bar"; but join.sql's uses of those names date back
only to December or so.
Since commit 7421f4b8 was back-patched to v10, back-patch a minimal
fix for that problem. The rest of this is just future-proofing.
Discussion: https://postgr.es/m/4627.1521070268@sss.pgh.pa.us
2018-03-15 22:08:51 +01:00
|
|
|
ALTER TABLE fd_pt1 DROP COLUMN c4;
|
|
|
|
ALTER TABLE fd_pt1 DROP COLUMN c5;
|
|
|
|
ALTER TABLE fd_pt1 DROP COLUMN c6;
|
|
|
|
ALTER TABLE fd_pt1 DROP COLUMN c7;
|
|
|
|
ALTER TABLE fd_pt1 DROP COLUMN c8;
|
|
|
|
\d+ fd_pt1
|
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
|
|
|
\d+ ft2
|
|
|
|
|
|
|
|
-- add constraints recursively
|
Clean up duplicate table and function names in regression tests.
Many of the objects we create during the regression tests are put in the
public schema, so that using the same names in different regression tests
creates a hazard of test failures if any two such scripts run concurrently.
This patch cleans up a bunch of latent hazards of that sort, as well as two
live hazards.
The current situation in this regard is far worse than it was a year or two
back, because practically all of the partitioning-related test cases have
reused table names with enthusiasm. I despaired of cleaning up that mess
within the five most-affected tests (create_table, alter_table, insert,
update, inherit); fortunately those don't run concurrently.
Other than partitioning problems, most of the issues boil down to using
names like "foo", "bar", "tmp", etc, without thought for the fact that
other test scripts might use similar names concurrently. I've made an
effort to make all such names more specific.
One of the live hazards was that commit 7421f4b8 caused with.sql to
create a table named "test", conflicting with a similarly-named table
in alter_table.sql; this was exposed in the buildfarm recently.
The other one was that join.sql and transactions.sql both create tables
named "foo" and "bar"; but join.sql's uses of those names date back
only to December or so.
Since commit 7421f4b8 was back-patched to v10, back-patch a minimal
fix for that problem. The rest of this is just future-proofing.
Discussion: https://postgr.es/m/4627.1521070268@sss.pgh.pa.us
2018-03-15 22:08:51 +01:00
|
|
|
ALTER TABLE fd_pt1 ADD CONSTRAINT fd_pt1chk1 CHECK (c1 > 0) NO INHERIT;
|
|
|
|
ALTER TABLE fd_pt1 ADD CONSTRAINT fd_pt1chk2 CHECK (c2 <> '');
|
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
|
|
|
-- 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)
|
Clean up duplicate table and function names in regression tests.
Many of the objects we create during the regression tests are put in the
public schema, so that using the same names in different regression tests
creates a hazard of test failures if any two such scripts run concurrently.
This patch cleans up a bunch of latent hazards of that sort, as well as two
live hazards.
The current situation in this regard is far worse than it was a year or two
back, because practically all of the partitioning-related test cases have
reused table names with enthusiasm. I despaired of cleaning up that mess
within the five most-affected tests (create_table, alter_table, insert,
update, inherit); fortunately those don't run concurrently.
Other than partitioning problems, most of the issues boil down to using
names like "foo", "bar", "tmp", etc, without thought for the fact that
other test scripts might use similar names concurrently. I've made an
effort to make all such names more specific.
One of the live hazards was that commit 7421f4b8 caused with.sql to
create a table named "test", conflicting with a similarly-named table
in alter_table.sql; this was exposed in the buildfarm recently.
The other one was that join.sql and transactions.sql both create tables
named "foo" and "bar"; but join.sql's uses of those names date back
only to December or so.
Since commit 7421f4b8 was back-patched to v10, back-patch a minimal
fix for that problem. The rest of this is just future-proofing.
Discussion: https://postgr.es/m/4627.1521070268@sss.pgh.pa.us
2018-03-15 22:08:51 +01:00
|
|
|
WHERE pc.relname = 'fd_pt1'
|
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
|
|
|
ORDER BY 1,2;
|
|
|
|
-- child does not inherit NO INHERIT constraints
|
Clean up duplicate table and function names in regression tests.
Many of the objects we create during the regression tests are put in the
public schema, so that using the same names in different regression tests
creates a hazard of test failures if any two such scripts run concurrently.
This patch cleans up a bunch of latent hazards of that sort, as well as two
live hazards.
The current situation in this regard is far worse than it was a year or two
back, because practically all of the partitioning-related test cases have
reused table names with enthusiasm. I despaired of cleaning up that mess
within the five most-affected tests (create_table, alter_table, insert,
update, inherit); fortunately those don't run concurrently.
Other than partitioning problems, most of the issues boil down to using
names like "foo", "bar", "tmp", etc, without thought for the fact that
other test scripts might use similar names concurrently. I've made an
effort to make all such names more specific.
One of the live hazards was that commit 7421f4b8 caused with.sql to
create a table named "test", conflicting with a similarly-named table
in alter_table.sql; this was exposed in the buildfarm recently.
The other one was that join.sql and transactions.sql both create tables
named "foo" and "bar"; but join.sql's uses of those names date back
only to December or so.
Since commit 7421f4b8 was back-patched to v10, back-patch a minimal
fix for that problem. The rest of this is just future-proofing.
Discussion: https://postgr.es/m/4627.1521070268@sss.pgh.pa.us
2018-03-15 22:08:51 +01:00
|
|
|
\d+ fd_pt1
|
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
|
|
|
\d+ ft2
|
|
|
|
DROP FOREIGN TABLE ft2; -- ERROR
|
|
|
|
DROP FOREIGN TABLE ft2 CASCADE;
|
|
|
|
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
|
Clean up duplicate table and function names in regression tests.
Many of the objects we create during the regression tests are put in the
public schema, so that using the same names in different regression tests
creates a hazard of test failures if any two such scripts run concurrently.
This patch cleans up a bunch of latent hazards of that sort, as well as two
live hazards.
The current situation in this regard is far worse than it was a year or two
back, because practically all of the partitioning-related test cases have
reused table names with enthusiasm. I despaired of cleaning up that mess
within the five most-affected tests (create_table, alter_table, insert,
update, inherit); fortunately those don't run concurrently.
Other than partitioning problems, most of the issues boil down to using
names like "foo", "bar", "tmp", etc, without thought for the fact that
other test scripts might use similar names concurrently. I've made an
effort to make all such names more specific.
One of the live hazards was that commit 7421f4b8 caused with.sql to
create a table named "test", conflicting with a similarly-named table
in alter_table.sql; this was exposed in the buildfarm recently.
The other one was that join.sql and transactions.sql both create tables
named "foo" and "bar"; but join.sql's uses of those names date back
only to December or so.
Since commit 7421f4b8 was back-patched to v10, back-patch a minimal
fix for that problem. The rest of this is just future-proofing.
Discussion: https://postgr.es/m/4627.1521070268@sss.pgh.pa.us
2018-03-15 22:08:51 +01:00
|
|
|
ALTER FOREIGN TABLE ft2 INHERIT fd_pt1; -- ERROR
|
|
|
|
ALTER FOREIGN TABLE ft2 ADD CONSTRAINT fd_pt1chk2 CHECK (c2 <> '');
|
|
|
|
ALTER FOREIGN TABLE ft2 INHERIT fd_pt1;
|
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 does not inherit NO INHERIT constraints
|
Clean up duplicate table and function names in regression tests.
Many of the objects we create during the regression tests are put in the
public schema, so that using the same names in different regression tests
creates a hazard of test failures if any two such scripts run concurrently.
This patch cleans up a bunch of latent hazards of that sort, as well as two
live hazards.
The current situation in this regard is far worse than it was a year or two
back, because practically all of the partitioning-related test cases have
reused table names with enthusiasm. I despaired of cleaning up that mess
within the five most-affected tests (create_table, alter_table, insert,
update, inherit); fortunately those don't run concurrently.
Other than partitioning problems, most of the issues boil down to using
names like "foo", "bar", "tmp", etc, without thought for the fact that
other test scripts might use similar names concurrently. I've made an
effort to make all such names more specific.
One of the live hazards was that commit 7421f4b8 caused with.sql to
create a table named "test", conflicting with a similarly-named table
in alter_table.sql; this was exposed in the buildfarm recently.
The other one was that join.sql and transactions.sql both create tables
named "foo" and "bar"; but join.sql's uses of those names date back
only to December or so.
Since commit 7421f4b8 was back-patched to v10, back-patch a minimal
fix for that problem. The rest of this is just future-proofing.
Discussion: https://postgr.es/m/4627.1521070268@sss.pgh.pa.us
2018-03-15 22:08:51 +01:00
|
|
|
\d+ fd_pt1
|
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
|
|
|
\d+ ft2
|
|
|
|
|
|
|
|
-- drop constraints recursively
|
Clean up duplicate table and function names in regression tests.
Many of the objects we create during the regression tests are put in the
public schema, so that using the same names in different regression tests
creates a hazard of test failures if any two such scripts run concurrently.
This patch cleans up a bunch of latent hazards of that sort, as well as two
live hazards.
The current situation in this regard is far worse than it was a year or two
back, because practically all of the partitioning-related test cases have
reused table names with enthusiasm. I despaired of cleaning up that mess
within the five most-affected tests (create_table, alter_table, insert,
update, inherit); fortunately those don't run concurrently.
Other than partitioning problems, most of the issues boil down to using
names like "foo", "bar", "tmp", etc, without thought for the fact that
other test scripts might use similar names concurrently. I've made an
effort to make all such names more specific.
One of the live hazards was that commit 7421f4b8 caused with.sql to
create a table named "test", conflicting with a similarly-named table
in alter_table.sql; this was exposed in the buildfarm recently.
The other one was that join.sql and transactions.sql both create tables
named "foo" and "bar"; but join.sql's uses of those names date back
only to December or so.
Since commit 7421f4b8 was back-patched to v10, back-patch a minimal
fix for that problem. The rest of this is just future-proofing.
Discussion: https://postgr.es/m/4627.1521070268@sss.pgh.pa.us
2018-03-15 22:08:51 +01:00
|
|
|
ALTER TABLE fd_pt1 DROP CONSTRAINT fd_pt1chk1 CASCADE;
|
|
|
|
ALTER TABLE fd_pt1 DROP CONSTRAINT fd_pt1chk2 CASCADE;
|
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
|
|
|
|
|
|
|
-- NOT VALID case
|
Clean up duplicate table and function names in regression tests.
Many of the objects we create during the regression tests are put in the
public schema, so that using the same names in different regression tests
creates a hazard of test failures if any two such scripts run concurrently.
This patch cleans up a bunch of latent hazards of that sort, as well as two
live hazards.
The current situation in this regard is far worse than it was a year or two
back, because practically all of the partitioning-related test cases have
reused table names with enthusiasm. I despaired of cleaning up that mess
within the five most-affected tests (create_table, alter_table, insert,
update, inherit); fortunately those don't run concurrently.
Other than partitioning problems, most of the issues boil down to using
names like "foo", "bar", "tmp", etc, without thought for the fact that
other test scripts might use similar names concurrently. I've made an
effort to make all such names more specific.
One of the live hazards was that commit 7421f4b8 caused with.sql to
create a table named "test", conflicting with a similarly-named table
in alter_table.sql; this was exposed in the buildfarm recently.
The other one was that join.sql and transactions.sql both create tables
named "foo" and "bar"; but join.sql's uses of those names date back
only to December or so.
Since commit 7421f4b8 was back-patched to v10, back-patch a minimal
fix for that problem. The rest of this is just future-proofing.
Discussion: https://postgr.es/m/4627.1521070268@sss.pgh.pa.us
2018-03-15 22:08:51 +01:00
|
|
|
INSERT INTO fd_pt1 VALUES (1, 'fd_pt1'::text, '1994-01-01'::date);
|
|
|
|
ALTER TABLE fd_pt1 ADD CONSTRAINT fd_pt1chk3 CHECK (c2 <> '') NOT VALID;
|
|
|
|
\d+ fd_pt1
|
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
|
|
|
\d+ ft2
|
|
|
|
-- VALIDATE CONSTRAINT need do nothing on foreign tables
|
Clean up duplicate table and function names in regression tests.
Many of the objects we create during the regression tests are put in the
public schema, so that using the same names in different regression tests
creates a hazard of test failures if any two such scripts run concurrently.
This patch cleans up a bunch of latent hazards of that sort, as well as two
live hazards.
The current situation in this regard is far worse than it was a year or two
back, because practically all of the partitioning-related test cases have
reused table names with enthusiasm. I despaired of cleaning up that mess
within the five most-affected tests (create_table, alter_table, insert,
update, inherit); fortunately those don't run concurrently.
Other than partitioning problems, most of the issues boil down to using
names like "foo", "bar", "tmp", etc, without thought for the fact that
other test scripts might use similar names concurrently. I've made an
effort to make all such names more specific.
One of the live hazards was that commit 7421f4b8 caused with.sql to
create a table named "test", conflicting with a similarly-named table
in alter_table.sql; this was exposed in the buildfarm recently.
The other one was that join.sql and transactions.sql both create tables
named "foo" and "bar"; but join.sql's uses of those names date back
only to December or so.
Since commit 7421f4b8 was back-patched to v10, back-patch a minimal
fix for that problem. The rest of this is just future-proofing.
Discussion: https://postgr.es/m/4627.1521070268@sss.pgh.pa.us
2018-03-15 22:08:51 +01:00
|
|
|
ALTER TABLE fd_pt1 VALIDATE CONSTRAINT fd_pt1chk3;
|
|
|
|
\d+ fd_pt1
|
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
|
|
|
\d+ ft2
|
|
|
|
|
|
|
|
-- changes name of an attribute recursively
|
Clean up duplicate table and function names in regression tests.
Many of the objects we create during the regression tests are put in the
public schema, so that using the same names in different regression tests
creates a hazard of test failures if any two such scripts run concurrently.
This patch cleans up a bunch of latent hazards of that sort, as well as two
live hazards.
The current situation in this regard is far worse than it was a year or two
back, because practically all of the partitioning-related test cases have
reused table names with enthusiasm. I despaired of cleaning up that mess
within the five most-affected tests (create_table, alter_table, insert,
update, inherit); fortunately those don't run concurrently.
Other than partitioning problems, most of the issues boil down to using
names like "foo", "bar", "tmp", etc, without thought for the fact that
other test scripts might use similar names concurrently. I've made an
effort to make all such names more specific.
One of the live hazards was that commit 7421f4b8 caused with.sql to
create a table named "test", conflicting with a similarly-named table
in alter_table.sql; this was exposed in the buildfarm recently.
The other one was that join.sql and transactions.sql both create tables
named "foo" and "bar"; but join.sql's uses of those names date back
only to December or so.
Since commit 7421f4b8 was back-patched to v10, back-patch a minimal
fix for that problem. The rest of this is just future-proofing.
Discussion: https://postgr.es/m/4627.1521070268@sss.pgh.pa.us
2018-03-15 22:08:51 +01:00
|
|
|
ALTER TABLE fd_pt1 RENAME COLUMN c1 TO f1;
|
|
|
|
ALTER TABLE fd_pt1 RENAME COLUMN c2 TO f2;
|
|
|
|
ALTER TABLE fd_pt1 RENAME COLUMN c3 TO f3;
|
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
|
|
|
-- changes name of a constraint recursively
|
Clean up duplicate table and function names in regression tests.
Many of the objects we create during the regression tests are put in the
public schema, so that using the same names in different regression tests
creates a hazard of test failures if any two such scripts run concurrently.
This patch cleans up a bunch of latent hazards of that sort, as well as two
live hazards.
The current situation in this regard is far worse than it was a year or two
back, because practically all of the partitioning-related test cases have
reused table names with enthusiasm. I despaired of cleaning up that mess
within the five most-affected tests (create_table, alter_table, insert,
update, inherit); fortunately those don't run concurrently.
Other than partitioning problems, most of the issues boil down to using
names like "foo", "bar", "tmp", etc, without thought for the fact that
other test scripts might use similar names concurrently. I've made an
effort to make all such names more specific.
One of the live hazards was that commit 7421f4b8 caused with.sql to
create a table named "test", conflicting with a similarly-named table
in alter_table.sql; this was exposed in the buildfarm recently.
The other one was that join.sql and transactions.sql both create tables
named "foo" and "bar"; but join.sql's uses of those names date back
only to December or so.
Since commit 7421f4b8 was back-patched to v10, back-patch a minimal
fix for that problem. The rest of this is just future-proofing.
Discussion: https://postgr.es/m/4627.1521070268@sss.pgh.pa.us
2018-03-15 22:08:51 +01:00
|
|
|
ALTER TABLE fd_pt1 RENAME CONSTRAINT fd_pt1chk3 TO f2_check;
|
|
|
|
\d+ fd_pt1
|
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
|
|
|
\d+ ft2
|
|
|
|
|
|
|
|
-- TRUNCATE doesn't work on foreign tables, either directly or recursively
|
|
|
|
TRUNCATE ft2; -- ERROR
|
Clean up duplicate table and function names in regression tests.
Many of the objects we create during the regression tests are put in the
public schema, so that using the same names in different regression tests
creates a hazard of test failures if any two such scripts run concurrently.
This patch cleans up a bunch of latent hazards of that sort, as well as two
live hazards.
The current situation in this regard is far worse than it was a year or two
back, because practically all of the partitioning-related test cases have
reused table names with enthusiasm. I despaired of cleaning up that mess
within the five most-affected tests (create_table, alter_table, insert,
update, inherit); fortunately those don't run concurrently.
Other than partitioning problems, most of the issues boil down to using
names like "foo", "bar", "tmp", etc, without thought for the fact that
other test scripts might use similar names concurrently. I've made an
effort to make all such names more specific.
One of the live hazards was that commit 7421f4b8 caused with.sql to
create a table named "test", conflicting with a similarly-named table
in alter_table.sql; this was exposed in the buildfarm recently.
The other one was that join.sql and transactions.sql both create tables
named "foo" and "bar"; but join.sql's uses of those names date back
only to December or so.
Since commit 7421f4b8 was back-patched to v10, back-patch a minimal
fix for that problem. The rest of this is just future-proofing.
Discussion: https://postgr.es/m/4627.1521070268@sss.pgh.pa.us
2018-03-15 22:08:51 +01:00
|
|
|
TRUNCATE fd_pt1; -- ERROR
|
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
|
|
|
|
Clean up duplicate table and function names in regression tests.
Many of the objects we create during the regression tests are put in the
public schema, so that using the same names in different regression tests
creates a hazard of test failures if any two such scripts run concurrently.
This patch cleans up a bunch of latent hazards of that sort, as well as two
live hazards.
The current situation in this regard is far worse than it was a year or two
back, because practically all of the partitioning-related test cases have
reused table names with enthusiasm. I despaired of cleaning up that mess
within the five most-affected tests (create_table, alter_table, insert,
update, inherit); fortunately those don't run concurrently.
Other than partitioning problems, most of the issues boil down to using
names like "foo", "bar", "tmp", etc, without thought for the fact that
other test scripts might use similar names concurrently. I've made an
effort to make all such names more specific.
One of the live hazards was that commit 7421f4b8 caused with.sql to
create a table named "test", conflicting with a similarly-named table
in alter_table.sql; this was exposed in the buildfarm recently.
The other one was that join.sql and transactions.sql both create tables
named "foo" and "bar"; but join.sql's uses of those names date back
only to December or so.
Since commit 7421f4b8 was back-patched to v10, back-patch a minimal
fix for that problem. The rest of this is just future-proofing.
Discussion: https://postgr.es/m/4627.1521070268@sss.pgh.pa.us
2018-03-15 22:08:51 +01:00
|
|
|
DROP TABLE fd_pt1 CASCADE;
|
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
|
|
|
|
2014-07-10 21:01:31 +02:00
|
|
|
-- IMPORT FOREIGN SCHEMA
|
|
|
|
IMPORT FOREIGN SCHEMA s1 FROM SERVER s9 INTO public; -- ERROR
|
|
|
|
IMPORT FOREIGN SCHEMA s1 LIMIT TO (t1) FROM SERVER s9 INTO public; --ERROR
|
|
|
|
IMPORT FOREIGN SCHEMA s1 EXCEPT (t1) FROM SERVER s9 INTO public; -- ERROR
|
|
|
|
IMPORT FOREIGN SCHEMA s1 EXCEPT (t1, t2) FROM SERVER s9 INTO public
|
|
|
|
OPTIONS (option1 'value1', option2 'value2'); -- ERROR
|
|
|
|
|
2011-01-02 05:48:11 +01:00
|
|
|
-- DROP FOREIGN TABLE
|
|
|
|
DROP FOREIGN TABLE no_table; -- ERROR
|
|
|
|
DROP FOREIGN TABLE IF EXISTS no_table;
|
|
|
|
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;
|
|
|
|
DROP OWNED BY regress_test_role2 CASCADE;
|
|
|
|
|
2017-03-08 17:26:03 +01:00
|
|
|
-- Foreign partition DDL stuff
|
Clean up duplicate table and function names in regression tests.
Many of the objects we create during the regression tests are put in the
public schema, so that using the same names in different regression tests
creates a hazard of test failures if any two such scripts run concurrently.
This patch cleans up a bunch of latent hazards of that sort, as well as two
live hazards.
The current situation in this regard is far worse than it was a year or two
back, because practically all of the partitioning-related test cases have
reused table names with enthusiasm. I despaired of cleaning up that mess
within the five most-affected tests (create_table, alter_table, insert,
update, inherit); fortunately those don't run concurrently.
Other than partitioning problems, most of the issues boil down to using
names like "foo", "bar", "tmp", etc, without thought for the fact that
other test scripts might use similar names concurrently. I've made an
effort to make all such names more specific.
One of the live hazards was that commit 7421f4b8 caused with.sql to
create a table named "test", conflicting with a similarly-named table
in alter_table.sql; this was exposed in the buildfarm recently.
The other one was that join.sql and transactions.sql both create tables
named "foo" and "bar"; but join.sql's uses of those names date back
only to December or so.
Since commit 7421f4b8 was back-patched to v10, back-patch a minimal
fix for that problem. The rest of this is just future-proofing.
Discussion: https://postgr.es/m/4627.1521070268@sss.pgh.pa.us
2018-03-15 22:08:51 +01:00
|
|
|
CREATE TABLE fd_pt2 (
|
2017-03-08 17:26:03 +01:00
|
|
|
c1 integer NOT NULL,
|
|
|
|
c2 text,
|
|
|
|
c3 date
|
|
|
|
) PARTITION BY LIST (c1);
|
Clean up duplicate table and function names in regression tests.
Many of the objects we create during the regression tests are put in the
public schema, so that using the same names in different regression tests
creates a hazard of test failures if any two such scripts run concurrently.
This patch cleans up a bunch of latent hazards of that sort, as well as two
live hazards.
The current situation in this regard is far worse than it was a year or two
back, because practically all of the partitioning-related test cases have
reused table names with enthusiasm. I despaired of cleaning up that mess
within the five most-affected tests (create_table, alter_table, insert,
update, inherit); fortunately those don't run concurrently.
Other than partitioning problems, most of the issues boil down to using
names like "foo", "bar", "tmp", etc, without thought for the fact that
other test scripts might use similar names concurrently. I've made an
effort to make all such names more specific.
One of the live hazards was that commit 7421f4b8 caused with.sql to
create a table named "test", conflicting with a similarly-named table
in alter_table.sql; this was exposed in the buildfarm recently.
The other one was that join.sql and transactions.sql both create tables
named "foo" and "bar"; but join.sql's uses of those names date back
only to December or so.
Since commit 7421f4b8 was back-patched to v10, back-patch a minimal
fix for that problem. The rest of this is just future-proofing.
Discussion: https://postgr.es/m/4627.1521070268@sss.pgh.pa.us
2018-03-15 22:08:51 +01:00
|
|
|
CREATE FOREIGN TABLE fd_pt2_1 PARTITION OF fd_pt2 FOR VALUES IN (1)
|
2017-03-08 17:26:03 +01:00
|
|
|
SERVER s0 OPTIONS (delimiter ',', quote '"', "be quoted" 'value');
|
Clean up duplicate table and function names in regression tests.
Many of the objects we create during the regression tests are put in the
public schema, so that using the same names in different regression tests
creates a hazard of test failures if any two such scripts run concurrently.
This patch cleans up a bunch of latent hazards of that sort, as well as two
live hazards.
The current situation in this regard is far worse than it was a year or two
back, because practically all of the partitioning-related test cases have
reused table names with enthusiasm. I despaired of cleaning up that mess
within the five most-affected tests (create_table, alter_table, insert,
update, inherit); fortunately those don't run concurrently.
Other than partitioning problems, most of the issues boil down to using
names like "foo", "bar", "tmp", etc, without thought for the fact that
other test scripts might use similar names concurrently. I've made an
effort to make all such names more specific.
One of the live hazards was that commit 7421f4b8 caused with.sql to
create a table named "test", conflicting with a similarly-named table
in alter_table.sql; this was exposed in the buildfarm recently.
The other one was that join.sql and transactions.sql both create tables
named "foo" and "bar"; but join.sql's uses of those names date back
only to December or so.
Since commit 7421f4b8 was back-patched to v10, back-patch a minimal
fix for that problem. The rest of this is just future-proofing.
Discussion: https://postgr.es/m/4627.1521070268@sss.pgh.pa.us
2018-03-15 22:08:51 +01:00
|
|
|
\d+ fd_pt2
|
|
|
|
\d+ fd_pt2_1
|
2017-03-08 17:26:03 +01:00
|
|
|
|
|
|
|
-- partition cannot have additional columns
|
Clean up duplicate table and function names in regression tests.
Many of the objects we create during the regression tests are put in the
public schema, so that using the same names in different regression tests
creates a hazard of test failures if any two such scripts run concurrently.
This patch cleans up a bunch of latent hazards of that sort, as well as two
live hazards.
The current situation in this regard is far worse than it was a year or two
back, because practically all of the partitioning-related test cases have
reused table names with enthusiasm. I despaired of cleaning up that mess
within the five most-affected tests (create_table, alter_table, insert,
update, inherit); fortunately those don't run concurrently.
Other than partitioning problems, most of the issues boil down to using
names like "foo", "bar", "tmp", etc, without thought for the fact that
other test scripts might use similar names concurrently. I've made an
effort to make all such names more specific.
One of the live hazards was that commit 7421f4b8 caused with.sql to
create a table named "test", conflicting with a similarly-named table
in alter_table.sql; this was exposed in the buildfarm recently.
The other one was that join.sql and transactions.sql both create tables
named "foo" and "bar"; but join.sql's uses of those names date back
only to December or so.
Since commit 7421f4b8 was back-patched to v10, back-patch a minimal
fix for that problem. The rest of this is just future-proofing.
Discussion: https://postgr.es/m/4627.1521070268@sss.pgh.pa.us
2018-03-15 22:08:51 +01:00
|
|
|
DROP FOREIGN TABLE fd_pt2_1;
|
|
|
|
CREATE FOREIGN TABLE fd_pt2_1 (
|
2017-03-08 17:26:03 +01:00
|
|
|
c1 integer NOT NULL,
|
|
|
|
c2 text,
|
|
|
|
c3 date,
|
|
|
|
c4 char
|
|
|
|
) SERVER s0 OPTIONS (delimiter ',', quote '"', "be quoted" 'value');
|
Clean up duplicate table and function names in regression tests.
Many of the objects we create during the regression tests are put in the
public schema, so that using the same names in different regression tests
creates a hazard of test failures if any two such scripts run concurrently.
This patch cleans up a bunch of latent hazards of that sort, as well as two
live hazards.
The current situation in this regard is far worse than it was a year or two
back, because practically all of the partitioning-related test cases have
reused table names with enthusiasm. I despaired of cleaning up that mess
within the five most-affected tests (create_table, alter_table, insert,
update, inherit); fortunately those don't run concurrently.
Other than partitioning problems, most of the issues boil down to using
names like "foo", "bar", "tmp", etc, without thought for the fact that
other test scripts might use similar names concurrently. I've made an
effort to make all such names more specific.
One of the live hazards was that commit 7421f4b8 caused with.sql to
create a table named "test", conflicting with a similarly-named table
in alter_table.sql; this was exposed in the buildfarm recently.
The other one was that join.sql and transactions.sql both create tables
named "foo" and "bar"; but join.sql's uses of those names date back
only to December or so.
Since commit 7421f4b8 was back-patched to v10, back-patch a minimal
fix for that problem. The rest of this is just future-proofing.
Discussion: https://postgr.es/m/4627.1521070268@sss.pgh.pa.us
2018-03-15 22:08:51 +01:00
|
|
|
\d+ fd_pt2_1
|
|
|
|
ALTER TABLE fd_pt2 ATTACH PARTITION fd_pt2_1 FOR VALUES IN (1); -- ERROR
|
2017-03-08 17:26:03 +01:00
|
|
|
|
Clean up duplicate table and function names in regression tests.
Many of the objects we create during the regression tests are put in the
public schema, so that using the same names in different regression tests
creates a hazard of test failures if any two such scripts run concurrently.
This patch cleans up a bunch of latent hazards of that sort, as well as two
live hazards.
The current situation in this regard is far worse than it was a year or two
back, because practically all of the partitioning-related test cases have
reused table names with enthusiasm. I despaired of cleaning up that mess
within the five most-affected tests (create_table, alter_table, insert,
update, inherit); fortunately those don't run concurrently.
Other than partitioning problems, most of the issues boil down to using
names like "foo", "bar", "tmp", etc, without thought for the fact that
other test scripts might use similar names concurrently. I've made an
effort to make all such names more specific.
One of the live hazards was that commit 7421f4b8 caused with.sql to
create a table named "test", conflicting with a similarly-named table
in alter_table.sql; this was exposed in the buildfarm recently.
The other one was that join.sql and transactions.sql both create tables
named "foo" and "bar"; but join.sql's uses of those names date back
only to December or so.
Since commit 7421f4b8 was back-patched to v10, back-patch a minimal
fix for that problem. The rest of this is just future-proofing.
Discussion: https://postgr.es/m/4627.1521070268@sss.pgh.pa.us
2018-03-15 22:08:51 +01:00
|
|
|
DROP FOREIGN TABLE fd_pt2_1;
|
|
|
|
\d+ fd_pt2
|
|
|
|
CREATE FOREIGN TABLE fd_pt2_1 (
|
2017-03-08 17:26:03 +01:00
|
|
|
c1 integer NOT NULL,
|
|
|
|
c2 text,
|
|
|
|
c3 date
|
|
|
|
) SERVER s0 OPTIONS (delimiter ',', quote '"', "be quoted" 'value');
|
Clean up duplicate table and function names in regression tests.
Many of the objects we create during the regression tests are put in the
public schema, so that using the same names in different regression tests
creates a hazard of test failures if any two such scripts run concurrently.
This patch cleans up a bunch of latent hazards of that sort, as well as two
live hazards.
The current situation in this regard is far worse than it was a year or two
back, because practically all of the partitioning-related test cases have
reused table names with enthusiasm. I despaired of cleaning up that mess
within the five most-affected tests (create_table, alter_table, insert,
update, inherit); fortunately those don't run concurrently.
Other than partitioning problems, most of the issues boil down to using
names like "foo", "bar", "tmp", etc, without thought for the fact that
other test scripts might use similar names concurrently. I've made an
effort to make all such names more specific.
One of the live hazards was that commit 7421f4b8 caused with.sql to
create a table named "test", conflicting with a similarly-named table
in alter_table.sql; this was exposed in the buildfarm recently.
The other one was that join.sql and transactions.sql both create tables
named "foo" and "bar"; but join.sql's uses of those names date back
only to December or so.
Since commit 7421f4b8 was back-patched to v10, back-patch a minimal
fix for that problem. The rest of this is just future-proofing.
Discussion: https://postgr.es/m/4627.1521070268@sss.pgh.pa.us
2018-03-15 22:08:51 +01:00
|
|
|
\d+ fd_pt2_1
|
2017-03-08 17:26:03 +01:00
|
|
|
-- no attach partition validation occurs for foreign tables
|
Clean up duplicate table and function names in regression tests.
Many of the objects we create during the regression tests are put in the
public schema, so that using the same names in different regression tests
creates a hazard of test failures if any two such scripts run concurrently.
This patch cleans up a bunch of latent hazards of that sort, as well as two
live hazards.
The current situation in this regard is far worse than it was a year or two
back, because practically all of the partitioning-related test cases have
reused table names with enthusiasm. I despaired of cleaning up that mess
within the five most-affected tests (create_table, alter_table, insert,
update, inherit); fortunately those don't run concurrently.
Other than partitioning problems, most of the issues boil down to using
names like "foo", "bar", "tmp", etc, without thought for the fact that
other test scripts might use similar names concurrently. I've made an
effort to make all such names more specific.
One of the live hazards was that commit 7421f4b8 caused with.sql to
create a table named "test", conflicting with a similarly-named table
in alter_table.sql; this was exposed in the buildfarm recently.
The other one was that join.sql and transactions.sql both create tables
named "foo" and "bar"; but join.sql's uses of those names date back
only to December or so.
Since commit 7421f4b8 was back-patched to v10, back-patch a minimal
fix for that problem. The rest of this is just future-proofing.
Discussion: https://postgr.es/m/4627.1521070268@sss.pgh.pa.us
2018-03-15 22:08:51 +01:00
|
|
|
ALTER TABLE fd_pt2 ATTACH PARTITION fd_pt2_1 FOR VALUES IN (1);
|
|
|
|
\d+ fd_pt2
|
|
|
|
\d+ fd_pt2_1
|
2017-03-08 17:26:03 +01:00
|
|
|
|
|
|
|
-- cannot add column to a partition
|
Clean up duplicate table and function names in regression tests.
Many of the objects we create during the regression tests are put in the
public schema, so that using the same names in different regression tests
creates a hazard of test failures if any two such scripts run concurrently.
This patch cleans up a bunch of latent hazards of that sort, as well as two
live hazards.
The current situation in this regard is far worse than it was a year or two
back, because practically all of the partitioning-related test cases have
reused table names with enthusiasm. I despaired of cleaning up that mess
within the five most-affected tests (create_table, alter_table, insert,
update, inherit); fortunately those don't run concurrently.
Other than partitioning problems, most of the issues boil down to using
names like "foo", "bar", "tmp", etc, without thought for the fact that
other test scripts might use similar names concurrently. I've made an
effort to make all such names more specific.
One of the live hazards was that commit 7421f4b8 caused with.sql to
create a table named "test", conflicting with a similarly-named table
in alter_table.sql; this was exposed in the buildfarm recently.
The other one was that join.sql and transactions.sql both create tables
named "foo" and "bar"; but join.sql's uses of those names date back
only to December or so.
Since commit 7421f4b8 was back-patched to v10, back-patch a minimal
fix for that problem. The rest of this is just future-proofing.
Discussion: https://postgr.es/m/4627.1521070268@sss.pgh.pa.us
2018-03-15 22:08:51 +01:00
|
|
|
ALTER TABLE fd_pt2_1 ADD c4 char;
|
2017-03-08 17:26:03 +01:00
|
|
|
|
|
|
|
-- ok to have a partition's own constraints though
|
Clean up duplicate table and function names in regression tests.
Many of the objects we create during the regression tests are put in the
public schema, so that using the same names in different regression tests
creates a hazard of test failures if any two such scripts run concurrently.
This patch cleans up a bunch of latent hazards of that sort, as well as two
live hazards.
The current situation in this regard is far worse than it was a year or two
back, because practically all of the partitioning-related test cases have
reused table names with enthusiasm. I despaired of cleaning up that mess
within the five most-affected tests (create_table, alter_table, insert,
update, inherit); fortunately those don't run concurrently.
Other than partitioning problems, most of the issues boil down to using
names like "foo", "bar", "tmp", etc, without thought for the fact that
other test scripts might use similar names concurrently. I've made an
effort to make all such names more specific.
One of the live hazards was that commit 7421f4b8 caused with.sql to
create a table named "test", conflicting with a similarly-named table
in alter_table.sql; this was exposed in the buildfarm recently.
The other one was that join.sql and transactions.sql both create tables
named "foo" and "bar"; but join.sql's uses of those names date back
only to December or so.
Since commit 7421f4b8 was back-patched to v10, back-patch a minimal
fix for that problem. The rest of this is just future-proofing.
Discussion: https://postgr.es/m/4627.1521070268@sss.pgh.pa.us
2018-03-15 22:08:51 +01:00
|
|
|
ALTER TABLE fd_pt2_1 ALTER c3 SET NOT NULL;
|
|
|
|
ALTER TABLE fd_pt2_1 ADD CONSTRAINT p21chk CHECK (c2 <> '');
|
|
|
|
\d+ fd_pt2
|
|
|
|
\d+ fd_pt2_1
|
2017-03-08 17:26:03 +01:00
|
|
|
|
|
|
|
-- cannot drop inherited NOT NULL constraint from a partition
|
Clean up duplicate table and function names in regression tests.
Many of the objects we create during the regression tests are put in the
public schema, so that using the same names in different regression tests
creates a hazard of test failures if any two such scripts run concurrently.
This patch cleans up a bunch of latent hazards of that sort, as well as two
live hazards.
The current situation in this regard is far worse than it was a year or two
back, because practically all of the partitioning-related test cases have
reused table names with enthusiasm. I despaired of cleaning up that mess
within the five most-affected tests (create_table, alter_table, insert,
update, inherit); fortunately those don't run concurrently.
Other than partitioning problems, most of the issues boil down to using
names like "foo", "bar", "tmp", etc, without thought for the fact that
other test scripts might use similar names concurrently. I've made an
effort to make all such names more specific.
One of the live hazards was that commit 7421f4b8 caused with.sql to
create a table named "test", conflicting with a similarly-named table
in alter_table.sql; this was exposed in the buildfarm recently.
The other one was that join.sql and transactions.sql both create tables
named "foo" and "bar"; but join.sql's uses of those names date back
only to December or so.
Since commit 7421f4b8 was back-patched to v10, back-patch a minimal
fix for that problem. The rest of this is just future-proofing.
Discussion: https://postgr.es/m/4627.1521070268@sss.pgh.pa.us
2018-03-15 22:08:51 +01:00
|
|
|
ALTER TABLE fd_pt2_1 ALTER c1 DROP NOT NULL;
|
2017-03-08 17:26:03 +01:00
|
|
|
|
|
|
|
-- partition must have parent's constraints
|
Clean up duplicate table and function names in regression tests.
Many of the objects we create during the regression tests are put in the
public schema, so that using the same names in different regression tests
creates a hazard of test failures if any two such scripts run concurrently.
This patch cleans up a bunch of latent hazards of that sort, as well as two
live hazards.
The current situation in this regard is far worse than it was a year or two
back, because practically all of the partitioning-related test cases have
reused table names with enthusiasm. I despaired of cleaning up that mess
within the five most-affected tests (create_table, alter_table, insert,
update, inherit); fortunately those don't run concurrently.
Other than partitioning problems, most of the issues boil down to using
names like "foo", "bar", "tmp", etc, without thought for the fact that
other test scripts might use similar names concurrently. I've made an
effort to make all such names more specific.
One of the live hazards was that commit 7421f4b8 caused with.sql to
create a table named "test", conflicting with a similarly-named table
in alter_table.sql; this was exposed in the buildfarm recently.
The other one was that join.sql and transactions.sql both create tables
named "foo" and "bar"; but join.sql's uses of those names date back
only to December or so.
Since commit 7421f4b8 was back-patched to v10, back-patch a minimal
fix for that problem. The rest of this is just future-proofing.
Discussion: https://postgr.es/m/4627.1521070268@sss.pgh.pa.us
2018-03-15 22:08:51 +01:00
|
|
|
ALTER TABLE fd_pt2 DETACH PARTITION fd_pt2_1;
|
|
|
|
ALTER TABLE fd_pt2 ALTER c2 SET NOT NULL;
|
|
|
|
\d+ fd_pt2
|
|
|
|
\d+ fd_pt2_1
|
|
|
|
ALTER TABLE fd_pt2 ATTACH PARTITION fd_pt2_1 FOR VALUES IN (1); -- ERROR
|
|
|
|
ALTER FOREIGN TABLE fd_pt2_1 ALTER c2 SET NOT NULL;
|
|
|
|
ALTER TABLE fd_pt2 ATTACH PARTITION fd_pt2_1 FOR VALUES IN (1);
|
|
|
|
|
|
|
|
ALTER TABLE fd_pt2 DETACH PARTITION fd_pt2_1;
|
|
|
|
ALTER TABLE fd_pt2 ADD CONSTRAINT fd_pt2chk1 CHECK (c1 > 0);
|
|
|
|
\d+ fd_pt2
|
|
|
|
\d+ fd_pt2_1
|
|
|
|
ALTER TABLE fd_pt2 ATTACH PARTITION fd_pt2_1 FOR VALUES IN (1); -- ERROR
|
|
|
|
ALTER FOREIGN TABLE fd_pt2_1 ADD CONSTRAINT fd_pt2chk1 CHECK (c1 > 0);
|
|
|
|
ALTER TABLE fd_pt2 ATTACH PARTITION fd_pt2_1 FOR VALUES IN (1);
|
2017-03-08 17:26:03 +01:00
|
|
|
|
|
|
|
-- TRUNCATE doesn't work on foreign tables, either directly or recursively
|
Clean up duplicate table and function names in regression tests.
Many of the objects we create during the regression tests are put in the
public schema, so that using the same names in different regression tests
creates a hazard of test failures if any two such scripts run concurrently.
This patch cleans up a bunch of latent hazards of that sort, as well as two
live hazards.
The current situation in this regard is far worse than it was a year or two
back, because practically all of the partitioning-related test cases have
reused table names with enthusiasm. I despaired of cleaning up that mess
within the five most-affected tests (create_table, alter_table, insert,
update, inherit); fortunately those don't run concurrently.
Other than partitioning problems, most of the issues boil down to using
names like "foo", "bar", "tmp", etc, without thought for the fact that
other test scripts might use similar names concurrently. I've made an
effort to make all such names more specific.
One of the live hazards was that commit 7421f4b8 caused with.sql to
create a table named "test", conflicting with a similarly-named table
in alter_table.sql; this was exposed in the buildfarm recently.
The other one was that join.sql and transactions.sql both create tables
named "foo" and "bar"; but join.sql's uses of those names date back
only to December or so.
Since commit 7421f4b8 was back-patched to v10, back-patch a minimal
fix for that problem. The rest of this is just future-proofing.
Discussion: https://postgr.es/m/4627.1521070268@sss.pgh.pa.us
2018-03-15 22:08:51 +01:00
|
|
|
TRUNCATE fd_pt2_1; -- ERROR
|
|
|
|
TRUNCATE fd_pt2; -- ERROR
|
2017-03-08 17:26:03 +01:00
|
|
|
|
Clean up duplicate table and function names in regression tests.
Many of the objects we create during the regression tests are put in the
public schema, so that using the same names in different regression tests
creates a hazard of test failures if any two such scripts run concurrently.
This patch cleans up a bunch of latent hazards of that sort, as well as two
live hazards.
The current situation in this regard is far worse than it was a year or two
back, because practically all of the partitioning-related test cases have
reused table names with enthusiasm. I despaired of cleaning up that mess
within the five most-affected tests (create_table, alter_table, insert,
update, inherit); fortunately those don't run concurrently.
Other than partitioning problems, most of the issues boil down to using
names like "foo", "bar", "tmp", etc, without thought for the fact that
other test scripts might use similar names concurrently. I've made an
effort to make all such names more specific.
One of the live hazards was that commit 7421f4b8 caused with.sql to
create a table named "test", conflicting with a similarly-named table
in alter_table.sql; this was exposed in the buildfarm recently.
The other one was that join.sql and transactions.sql both create tables
named "foo" and "bar"; but join.sql's uses of those names date back
only to December or so.
Since commit 7421f4b8 was back-patched to v10, back-patch a minimal
fix for that problem. The rest of this is just future-proofing.
Discussion: https://postgr.es/m/4627.1521070268@sss.pgh.pa.us
2018-03-15 22:08:51 +01:00
|
|
|
DROP FOREIGN TABLE fd_pt2_1;
|
|
|
|
DROP TABLE fd_pt2;
|
2017-03-08 17:26:03 +01:00
|
|
|
|
Clarify use of temporary tables within partition trees
Since their introduction, partition trees have been a bit lossy
regarding temporary relations. Inheritance trees respect the following
patterns:
1) a child relation can be temporary if the parent is permanent.
2) a child relation can be temporary if the parent is temporary.
3) a child relation cannot be permanent if the parent is temporary.
4) The use of temporary relations also imply that when both parent and
child need to be from the same sessions.
Partitions share many similar patterns with inheritance, however the
handling of the partition bounds make the situation a bit tricky for
case 1) as the partition code bases a lot of its lookup code upon
PartitionDesc which does not really look after relpersistence. This
causes for example a temporary partition created by session A to be
visible by another session B, preventing this session B to create an
extra partition which overlaps with the temporary one created by A with
a non-intuitive error message. There could be use-cases where mixing
permanent partitioned tables with temporary partitions make sense, but
that would be a new feature. Partitions respect 2), 3) and 4) already.
It is a bit depressing to see those error checks happening in
MergeAttributes() whose purpose is different, but that's left as future
refactoring work.
Back-patch down to 10, which is where partitioning has been introduced,
except that default partitions do not apply there. Documentation also
includes limitations related to the use of temporary tables with
partition trees.
Reported-by: David Rowley
Author: Amit Langote, Michael Paquier
Reviewed-by: Ashutosh Bapat, Amit Langote, Michael Paquier
Discussion: https://postgr.es/m/CAKJS1f94Ojk0og9GMkRHGt8wHTW=ijq5KzJKuoBoqWLwSVwGmw@mail.gmail.com
2018-06-20 03:42:25 +02:00
|
|
|
-- foreign table cannot be part of partition tree made of temporary
|
|
|
|
-- relations.
|
|
|
|
CREATE TEMP TABLE temp_parted (a int) PARTITION BY LIST (a);
|
|
|
|
CREATE FOREIGN TABLE foreign_part PARTITION OF temp_parted DEFAULT
|
|
|
|
SERVER s0; -- ERROR
|
|
|
|
CREATE FOREIGN TABLE foreign_part (a int) SERVER s0;
|
|
|
|
ALTER TABLE temp_parted ATTACH PARTITION foreign_part DEFAULT; -- ERROR
|
|
|
|
DROP FOREIGN TABLE foreign_part;
|
|
|
|
DROP TABLE temp_parted;
|
|
|
|
|
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
|
2009-03-09 16:04:21 +01:00
|
|
|
DROP SERVER t1 CASCADE;
|
2008-12-19 17:25:19 +01:00
|
|
|
DROP USER MAPPING FOR regress_test_role SERVER s6;
|
|
|
|
DROP FOREIGN DATA WRAPPER foo CASCADE;
|
|
|
|
DROP SERVER s8 CASCADE;
|
|
|
|
DROP ROLE regress_test_indirect;
|
|
|
|
DROP ROLE regress_test_role;
|
2016-07-18 00:42:31 +02:00
|
|
|
DROP ROLE regress_unprivileged_role; -- ERROR
|
|
|
|
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;
|
|
|
|
\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;
|
2008-12-19 17:25:19 +01:00
|
|
|
SELECT srvname, srvoptions FROM pg_foreign_server;
|
|
|
|
SELECT * FROM pg_user_mapping;
|