I’m trying to setup temporary tables for unit-testing purposes. So far I managed to create a temporary table which copies the structure of an existing table:
CREATE TEMP TABLE t_mytable (LIKE mytable INCLUDING DEFAULTS);
But this lacks the data from the original table. I can copy the data into the temporary table by using a CREATE TABLE AS statement instead:
CREATE TEMP TABLE t_mytable AS SELECT * FROM mytable;
But then the structure of t_mytable will not be identical, e.g. column sizes and default values are different. Is there a single statement which copies everything?
Another problem with the first query using LIKE is that the key column still references the SEQUENCE of the original table, and thus increments it on insertion. Is there an easy way to create the new table with its own sequence, or will I have to set up a new sequence by hand?
Postgres 10 or later
Postgres 10 introduced
IDENTITYcolumns conforming to the SQL standard (with minor extensions). The ID column of your table would look something like:Syntax in the manual.
Using this instead of a traditional
serialcolumn avoids your problem with sequences.IDENTITYcolumns use exclusive, dedicated sequences automatically, even when the specification is copied withLIKE. The manual:And:
The solution is simpler now:
As demonstrated, you can still use
setval()to set the sequence’s current value. A singleSELECTdoes the trick.pg_get_serial_sequence()]6 gets the name of the sequence.db<>fiddle here
Related:
Original (old) answer
You can take the create script from a database dump or a GUI like pgAdmin (which reverse-engineers database object creation scripts), create an identical copy (with separate sequence for the
serialcolumn), and then run:The copy cannot be 100% identical if both tables reside in the same schema. Obviously, the table name has to be different. Index names would conflict, too. Retrieving serial numbers from the same sequence would probably not be in your best interest, either. So you have to (at least) adjust the names.
Placing the copy in a different schema avoids all of these conflicts. While you create a temporary table from a regular table like you demonstrated, that’s automatically the case since temp tables reside in their own temporary schema.
Or look at Francisco’s answer for DDL code to copy directly.