2000-01-06 07:40:54 +01:00
|
|
|
--
|
|
|
|
-- SELECT_INTO
|
|
|
|
--
|
|
|
|
SELECT *
|
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
|
|
|
INTO TABLE sitmp1
|
2000-06-04 19:52:54 +02:00
|
|
|
FROM onek
|
1997-04-06 10:29:57 +02:00
|
|
|
WHERE onek.unique1 < 2;
|
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 sitmp1;
|
2000-01-06 07:40:54 +01:00
|
|
|
SELECT *
|
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
|
|
|
INTO TABLE sitmp1
|
2000-06-04 19:52:54 +02:00
|
|
|
FROM onek2
|
1997-04-06 10:29:57 +02:00
|
|
|
WHERE onek2.unique1 < 2;
|
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 sitmp1;
|
2011-11-22 22:16:26 +01:00
|
|
|
--
|
|
|
|
-- SELECT INTO and INSERT permission, if owner is not allowed to insert.
|
|
|
|
--
|
|
|
|
CREATE SCHEMA selinto_schema;
|
2016-07-18 00:42:31 +02:00
|
|
|
CREATE USER regress_selinto_user;
|
|
|
|
ALTER DEFAULT PRIVILEGES FOR ROLE regress_selinto_user
|
|
|
|
REVOKE INSERT ON TABLES FROM regress_selinto_user;
|
2011-11-22 22:16:26 +01:00
|
|
|
GRANT ALL ON SCHEMA selinto_schema TO public;
|
2016-07-18 00:42:31 +02:00
|
|
|
SET SESSION AUTHORIZATION regress_selinto_user;
|
2020-11-21 11:45:30 +01:00
|
|
|
-- WITH DATA, passes.
|
|
|
|
CREATE TABLE selinto_schema.tbl_withdata1 (a)
|
|
|
|
AS SELECT generate_series(1,3) WITH DATA;
|
|
|
|
INSERT INTO selinto_schema.tbl_withdata1 VALUES (4);
|
|
|
|
ERROR: permission denied for table tbl_withdata1
|
2020-11-16 03:52:40 +01:00
|
|
|
EXPLAIN (ANALYZE, COSTS OFF, SUMMARY OFF, TIMING OFF)
|
2020-11-21 11:45:30 +01:00
|
|
|
CREATE TABLE selinto_schema.tbl_withdata2 (a) AS
|
|
|
|
SELECT generate_series(1,3) WITH DATA;
|
|
|
|
QUERY PLAN
|
|
|
|
--------------------------------------
|
|
|
|
ProjectSet (actual rows=3 loops=1)
|
|
|
|
-> Result (actual rows=1 loops=1)
|
|
|
|
(2 rows)
|
|
|
|
|
2020-11-16 03:52:40 +01:00
|
|
|
-- WITH NO DATA, passes.
|
|
|
|
CREATE TABLE selinto_schema.tbl_nodata1 (a) AS
|
2020-11-21 11:45:30 +01:00
|
|
|
SELECT generate_series(1,3) WITH NO DATA;
|
2020-11-16 03:52:40 +01:00
|
|
|
EXPLAIN (ANALYZE, COSTS OFF, SUMMARY OFF, TIMING OFF)
|
|
|
|
CREATE TABLE selinto_schema.tbl_nodata2 (a) AS
|
2020-11-21 11:45:30 +01:00
|
|
|
SELECT generate_series(1,3) WITH NO DATA;
|
|
|
|
QUERY PLAN
|
|
|
|
-------------------------------
|
|
|
|
ProjectSet (never executed)
|
|
|
|
-> Result (never executed)
|
2020-11-16 03:52:40 +01:00
|
|
|
(2 rows)
|
|
|
|
|
2020-11-21 11:45:30 +01:00
|
|
|
-- EXECUTE and WITH DATA, passes.
|
|
|
|
PREPARE data_sel AS SELECT generate_series(1,3);
|
|
|
|
CREATE TABLE selinto_schema.tbl_withdata3 (a) AS
|
2020-11-16 03:52:40 +01:00
|
|
|
EXECUTE data_sel WITH DATA;
|
|
|
|
EXPLAIN (ANALYZE, COSTS OFF, SUMMARY OFF, TIMING OFF)
|
2020-11-21 11:45:30 +01:00
|
|
|
CREATE TABLE selinto_schema.tbl_withdata4 (a) AS
|
2020-11-16 03:52:40 +01:00
|
|
|
EXECUTE data_sel WITH DATA;
|
2020-11-21 11:45:30 +01:00
|
|
|
QUERY PLAN
|
|
|
|
--------------------------------------
|
|
|
|
ProjectSet (actual rows=3 loops=1)
|
|
|
|
-> Result (actual rows=1 loops=1)
|
|
|
|
(2 rows)
|
|
|
|
|
2020-11-16 03:52:40 +01:00
|
|
|
-- EXECUTE and WITH NO DATA, passes.
|
|
|
|
CREATE TABLE selinto_schema.tbl_nodata3 (a) AS
|
|
|
|
EXECUTE data_sel WITH NO DATA;
|
|
|
|
EXPLAIN (ANALYZE, COSTS OFF, SUMMARY OFF, TIMING OFF)
|
|
|
|
CREATE TABLE selinto_schema.tbl_nodata4 (a) AS
|
|
|
|
EXECUTE data_sel WITH NO DATA;
|
2020-11-21 11:45:30 +01:00
|
|
|
QUERY PLAN
|
|
|
|
-------------------------------
|
|
|
|
ProjectSet (never executed)
|
|
|
|
-> Result (never executed)
|
2020-11-16 03:52:40 +01:00
|
|
|
(2 rows)
|
|
|
|
|
2011-11-22 22:16:26 +01:00
|
|
|
RESET SESSION AUTHORIZATION;
|
2016-07-18 00:42:31 +02:00
|
|
|
ALTER DEFAULT PRIVILEGES FOR ROLE regress_selinto_user
|
|
|
|
GRANT INSERT ON TABLES TO regress_selinto_user;
|
|
|
|
SET SESSION AUTHORIZATION regress_selinto_user;
|
2011-11-22 22:16:26 +01:00
|
|
|
RESET SESSION AUTHORIZATION;
|
2020-11-21 11:45:30 +01:00
|
|
|
DEALLOCATE data_sel;
|
2011-11-22 22:16:26 +01:00
|
|
|
DROP SCHEMA selinto_schema CASCADE;
|
2020-11-21 11:45:30 +01:00
|
|
|
NOTICE: drop cascades to 8 other objects
|
|
|
|
DETAIL: drop cascades to table selinto_schema.tbl_withdata1
|
|
|
|
drop cascades to table selinto_schema.tbl_withdata2
|
|
|
|
drop cascades to table selinto_schema.tbl_nodata1
|
2020-11-16 03:52:40 +01:00
|
|
|
drop cascades to table selinto_schema.tbl_nodata2
|
2020-11-21 11:45:30 +01:00
|
|
|
drop cascades to table selinto_schema.tbl_withdata3
|
|
|
|
drop cascades to table selinto_schema.tbl_withdata4
|
2020-11-16 03:52:40 +01:00
|
|
|
drop cascades to table selinto_schema.tbl_nodata3
|
|
|
|
drop cascades to table selinto_schema.tbl_nodata4
|
2016-07-18 00:42:31 +02:00
|
|
|
DROP USER regress_selinto_user;
|
2016-06-27 21:57:21 +02:00
|
|
|
-- Tests for WITH NO DATA and column name consistency
|
|
|
|
CREATE TABLE ctas_base (i int, j int);
|
|
|
|
INSERT INTO ctas_base VALUES (1, 2);
|
|
|
|
CREATE TABLE ctas_nodata (ii, jj, kk) AS SELECT i, j FROM ctas_base; -- Error
|
|
|
|
ERROR: too many column names were specified
|
|
|
|
CREATE TABLE ctas_nodata (ii, jj, kk) AS SELECT i, j FROM ctas_base WITH NO DATA; -- Error
|
|
|
|
ERROR: too many column names were specified
|
|
|
|
CREATE TABLE ctas_nodata (ii, jj) AS SELECT i, j FROM ctas_base; -- OK
|
|
|
|
CREATE TABLE ctas_nodata_2 (ii, jj) AS SELECT i, j FROM ctas_base WITH NO DATA; -- OK
|
|
|
|
CREATE TABLE ctas_nodata_3 (ii) AS SELECT i, j FROM ctas_base; -- OK
|
|
|
|
CREATE TABLE ctas_nodata_4 (ii) AS SELECT i, j FROM ctas_base WITH NO DATA; -- OK
|
|
|
|
SELECT * FROM ctas_nodata;
|
|
|
|
ii | jj
|
|
|
|
----+----
|
|
|
|
1 | 2
|
|
|
|
(1 row)
|
|
|
|
|
|
|
|
SELECT * FROM ctas_nodata_2;
|
|
|
|
ii | jj
|
|
|
|
----+----
|
|
|
|
(0 rows)
|
|
|
|
|
|
|
|
SELECT * FROM ctas_nodata_3;
|
|
|
|
ii | j
|
|
|
|
----+---
|
|
|
|
1 | 2
|
|
|
|
(1 row)
|
|
|
|
|
|
|
|
SELECT * FROM ctas_nodata_4;
|
|
|
|
ii | j
|
|
|
|
----+---
|
|
|
|
(0 rows)
|
|
|
|
|
|
|
|
DROP TABLE ctas_base;
|
|
|
|
DROP TABLE ctas_nodata;
|
|
|
|
DROP TABLE ctas_nodata_2;
|
|
|
|
DROP TABLE ctas_nodata_3;
|
|
|
|
DROP TABLE ctas_nodata_4;
|
2012-01-05 00:30:55 +01:00
|
|
|
--
|
|
|
|
-- CREATE TABLE AS/SELECT INTO as last command in a SQL function
|
|
|
|
-- have been known to cause problems
|
|
|
|
--
|
|
|
|
CREATE FUNCTION make_table() RETURNS VOID
|
|
|
|
AS $$
|
|
|
|
CREATE TABLE created_table AS SELECT * FROM int8_tbl;
|
|
|
|
$$ LANGUAGE SQL;
|
|
|
|
SELECT make_table();
|
|
|
|
make_table
|
|
|
|
------------
|
|
|
|
|
|
|
|
(1 row)
|
|
|
|
|
|
|
|
SELECT * FROM created_table;
|
|
|
|
q1 | q2
|
|
|
|
------------------+-------------------
|
|
|
|
123 | 456
|
|
|
|
123 | 4567890123456789
|
|
|
|
4567890123456789 | 123
|
|
|
|
4567890123456789 | 4567890123456789
|
|
|
|
4567890123456789 | -4567890123456789
|
|
|
|
(5 rows)
|
|
|
|
|
2019-02-07 01:21:57 +01:00
|
|
|
-- Try EXPLAIN ANALYZE SELECT INTO and EXPLAIN ANALYZE CREATE TABLE AS
|
|
|
|
-- WITH NO DATA, but hide the outputs since they won't be stable.
|
2016-03-15 00:48:46 +01:00
|
|
|
DO $$
|
|
|
|
BEGIN
|
|
|
|
EXECUTE 'EXPLAIN ANALYZE SELECT * INTO TABLE easi FROM int8_tbl';
|
2019-02-07 01:21:57 +01:00
|
|
|
EXECUTE 'EXPLAIN ANALYZE CREATE TABLE easi2 AS SELECT * FROM int8_tbl WITH NO DATA';
|
2016-03-15 00:48:46 +01:00
|
|
|
END$$;
|
2012-01-05 00:30:55 +01:00
|
|
|
DROP TABLE created_table;
|
2019-02-07 01:21:57 +01:00
|
|
|
DROP TABLE easi, easi2;
|
Restructure SELECT INTO's parsetree representation into CreateTableAsStmt.
Making this operation look like a utility statement seems generally a good
idea, and particularly so in light of the desire to provide command
triggers for utility statements. The original choice of representing it as
SELECT with an IntoClause appendage had metastasized into rather a lot of
places, unfortunately, so that this patch is a great deal more complicated
than one might at first expect.
In particular, keeping EXPLAIN working for SELECT INTO and CREATE TABLE AS
subcommands required restructuring some EXPLAIN-related APIs. Add-on code
that calls ExplainOnePlan or ExplainOneUtility, or uses
ExplainOneQuery_hook, will need adjustment.
Also, the cases PREPARE ... SELECT INTO and CREATE RULE ... SELECT INTO,
which formerly were accepted though undocumented, are no longer accepted.
The PREPARE case can be replaced with use of CREATE TABLE AS EXECUTE.
The CREATE RULE case doesn't seem to have much real-world use (since the
rule would work only once before failing with "table already exists"),
so we'll not bother with that one.
Both SELECT INTO and CREATE TABLE AS still return a command tag of
"SELECT nnnn". There was some discussion of returning "CREATE TABLE nnnn",
but for the moment backwards compatibility wins the day.
Andres Freund and Tom Lane
2012-03-20 02:37:19 +01:00
|
|
|
--
|
|
|
|
-- Disallowed uses of SELECT ... INTO. All should fail
|
|
|
|
--
|
2022-02-08 21:30:38 +01:00
|
|
|
DECLARE foo CURSOR FOR SELECT 1 INTO int4_tbl;
|
Restructure SELECT INTO's parsetree representation into CreateTableAsStmt.
Making this operation look like a utility statement seems generally a good
idea, and particularly so in light of the desire to provide command
triggers for utility statements. The original choice of representing it as
SELECT with an IntoClause appendage had metastasized into rather a lot of
places, unfortunately, so that this patch is a great deal more complicated
than one might at first expect.
In particular, keeping EXPLAIN working for SELECT INTO and CREATE TABLE AS
subcommands required restructuring some EXPLAIN-related APIs. Add-on code
that calls ExplainOnePlan or ExplainOneUtility, or uses
ExplainOneQuery_hook, will need adjustment.
Also, the cases PREPARE ... SELECT INTO and CREATE RULE ... SELECT INTO,
which formerly were accepted though undocumented, are no longer accepted.
The PREPARE case can be replaced with use of CREATE TABLE AS EXECUTE.
The CREATE RULE case doesn't seem to have much real-world use (since the
rule would work only once before failing with "table already exists"),
so we'll not bother with that one.
Both SELECT INTO and CREATE TABLE AS still return a command tag of
"SELECT nnnn". There was some discussion of returning "CREATE TABLE nnnn",
but for the moment backwards compatibility wins the day.
Andres Freund and Tom Lane
2012-03-20 02:37:19 +01:00
|
|
|
ERROR: SELECT ... INTO is not allowed here
|
2022-02-08 21:30:38 +01:00
|
|
|
LINE 1: DECLARE foo CURSOR FOR SELECT 1 INTO int4_tbl;
|
Restructure SELECT INTO's parsetree representation into CreateTableAsStmt.
Making this operation look like a utility statement seems generally a good
idea, and particularly so in light of the desire to provide command
triggers for utility statements. The original choice of representing it as
SELECT with an IntoClause appendage had metastasized into rather a lot of
places, unfortunately, so that this patch is a great deal more complicated
than one might at first expect.
In particular, keeping EXPLAIN working for SELECT INTO and CREATE TABLE AS
subcommands required restructuring some EXPLAIN-related APIs. Add-on code
that calls ExplainOnePlan or ExplainOneUtility, or uses
ExplainOneQuery_hook, will need adjustment.
Also, the cases PREPARE ... SELECT INTO and CREATE RULE ... SELECT INTO,
which formerly were accepted though undocumented, are no longer accepted.
The PREPARE case can be replaced with use of CREATE TABLE AS EXECUTE.
The CREATE RULE case doesn't seem to have much real-world use (since the
rule would work only once before failing with "table already exists"),
so we'll not bother with that one.
Both SELECT INTO and CREATE TABLE AS still return a command tag of
"SELECT nnnn". There was some discussion of returning "CREATE TABLE nnnn",
but for the moment backwards compatibility wins the day.
Andres Freund and Tom Lane
2012-03-20 02:37:19 +01:00
|
|
|
^
|
|
|
|
COPY (SELECT 1 INTO frak UNION SELECT 2) TO 'blob';
|
|
|
|
ERROR: COPY (SELECT INTO) is not supported
|
|
|
|
SELECT * FROM (SELECT 1 INTO f) bar;
|
|
|
|
ERROR: SELECT ... INTO is not allowed here
|
|
|
|
LINE 1: SELECT * FROM (SELECT 1 INTO f) bar;
|
|
|
|
^
|
2022-02-08 21:30:38 +01:00
|
|
|
CREATE VIEW foo AS SELECT 1 INTO int4_tbl;
|
Restructure SELECT INTO's parsetree representation into CreateTableAsStmt.
Making this operation look like a utility statement seems generally a good
idea, and particularly so in light of the desire to provide command
triggers for utility statements. The original choice of representing it as
SELECT with an IntoClause appendage had metastasized into rather a lot of
places, unfortunately, so that this patch is a great deal more complicated
than one might at first expect.
In particular, keeping EXPLAIN working for SELECT INTO and CREATE TABLE AS
subcommands required restructuring some EXPLAIN-related APIs. Add-on code
that calls ExplainOnePlan or ExplainOneUtility, or uses
ExplainOneQuery_hook, will need adjustment.
Also, the cases PREPARE ... SELECT INTO and CREATE RULE ... SELECT INTO,
which formerly were accepted though undocumented, are no longer accepted.
The PREPARE case can be replaced with use of CREATE TABLE AS EXECUTE.
The CREATE RULE case doesn't seem to have much real-world use (since the
rule would work only once before failing with "table already exists"),
so we'll not bother with that one.
Both SELECT INTO and CREATE TABLE AS still return a command tag of
"SELECT nnnn". There was some discussion of returning "CREATE TABLE nnnn",
but for the moment backwards compatibility wins the day.
Andres Freund and Tom Lane
2012-03-20 02:37:19 +01:00
|
|
|
ERROR: views must not contain SELECT INTO
|
2022-02-08 21:30:38 +01:00
|
|
|
INSERT INTO int4_tbl SELECT 1 INTO f;
|
Restructure SELECT INTO's parsetree representation into CreateTableAsStmt.
Making this operation look like a utility statement seems generally a good
idea, and particularly so in light of the desire to provide command
triggers for utility statements. The original choice of representing it as
SELECT with an IntoClause appendage had metastasized into rather a lot of
places, unfortunately, so that this patch is a great deal more complicated
than one might at first expect.
In particular, keeping EXPLAIN working for SELECT INTO and CREATE TABLE AS
subcommands required restructuring some EXPLAIN-related APIs. Add-on code
that calls ExplainOnePlan or ExplainOneUtility, or uses
ExplainOneQuery_hook, will need adjustment.
Also, the cases PREPARE ... SELECT INTO and CREATE RULE ... SELECT INTO,
which formerly were accepted though undocumented, are no longer accepted.
The PREPARE case can be replaced with use of CREATE TABLE AS EXECUTE.
The CREATE RULE case doesn't seem to have much real-world use (since the
rule would work only once before failing with "table already exists"),
so we'll not bother with that one.
Both SELECT INTO and CREATE TABLE AS still return a command tag of
"SELECT nnnn". There was some discussion of returning "CREATE TABLE nnnn",
but for the moment backwards compatibility wins the day.
Andres Freund and Tom Lane
2012-03-20 02:37:19 +01:00
|
|
|
ERROR: SELECT ... INTO is not allowed here
|
2022-02-08 21:30:38 +01:00
|
|
|
LINE 1: INSERT INTO int4_tbl SELECT 1 INTO f;
|
|
|
|
^
|
2020-12-30 13:23:24 +01:00
|
|
|
-- Test CREATE TABLE AS ... IF NOT EXISTS
|
|
|
|
CREATE TABLE ctas_ine_tbl AS SELECT 1;
|
|
|
|
CREATE TABLE ctas_ine_tbl AS SELECT 1 / 0; -- error
|
|
|
|
ERROR: relation "ctas_ine_tbl" already exists
|
|
|
|
CREATE TABLE IF NOT EXISTS ctas_ine_tbl AS SELECT 1 / 0; -- ok
|
|
|
|
NOTICE: relation "ctas_ine_tbl" already exists, skipping
|
|
|
|
CREATE TABLE ctas_ine_tbl AS SELECT 1 / 0 WITH NO DATA; -- error
|
|
|
|
ERROR: relation "ctas_ine_tbl" already exists
|
|
|
|
CREATE TABLE IF NOT EXISTS ctas_ine_tbl AS SELECT 1 / 0 WITH NO DATA; -- ok
|
|
|
|
NOTICE: relation "ctas_ine_tbl" already exists, skipping
|
|
|
|
EXPLAIN (ANALYZE, COSTS OFF, SUMMARY OFF, TIMING OFF)
|
|
|
|
CREATE TABLE ctas_ine_tbl AS SELECT 1 / 0; -- error
|
|
|
|
ERROR: relation "ctas_ine_tbl" already exists
|
|
|
|
EXPLAIN (ANALYZE, COSTS OFF, SUMMARY OFF, TIMING OFF)
|
|
|
|
CREATE TABLE IF NOT EXISTS ctas_ine_tbl AS SELECT 1 / 0; -- ok
|
|
|
|
NOTICE: relation "ctas_ine_tbl" already exists, skipping
|
|
|
|
QUERY PLAN
|
|
|
|
------------
|
|
|
|
(0 rows)
|
|
|
|
|
|
|
|
EXPLAIN (ANALYZE, COSTS OFF, SUMMARY OFF, TIMING OFF)
|
|
|
|
CREATE TABLE ctas_ine_tbl AS SELECT 1 / 0 WITH NO DATA; -- error
|
|
|
|
ERROR: relation "ctas_ine_tbl" already exists
|
|
|
|
EXPLAIN (ANALYZE, COSTS OFF, SUMMARY OFF, TIMING OFF)
|
|
|
|
CREATE TABLE IF NOT EXISTS ctas_ine_tbl AS SELECT 1 / 0 WITH NO DATA; -- ok
|
|
|
|
NOTICE: relation "ctas_ine_tbl" already exists, skipping
|
|
|
|
QUERY PLAN
|
|
|
|
------------
|
|
|
|
(0 rows)
|
|
|
|
|
|
|
|
PREPARE ctas_ine_query AS SELECT 1 / 0;
|
|
|
|
EXPLAIN (ANALYZE, COSTS OFF, SUMMARY OFF, TIMING OFF)
|
|
|
|
CREATE TABLE ctas_ine_tbl AS EXECUTE ctas_ine_query; -- error
|
|
|
|
ERROR: relation "ctas_ine_tbl" already exists
|
|
|
|
EXPLAIN (ANALYZE, COSTS OFF, SUMMARY OFF, TIMING OFF)
|
|
|
|
CREATE TABLE IF NOT EXISTS ctas_ine_tbl AS EXECUTE ctas_ine_query; -- ok
|
|
|
|
NOTICE: relation "ctas_ine_tbl" already exists, skipping
|
|
|
|
QUERY PLAN
|
|
|
|
------------
|
|
|
|
(0 rows)
|
|
|
|
|
|
|
|
DROP TABLE ctas_ine_tbl;
|