At 15:50 22/11/00 +0800, Christopher Kings-Lynne wrote:
I've been examining the pg_dump source and output, and I've come to the
conclusion that I can modify it so that UNIQUE constraints appear as part of
the CREATE TABLE statement, rather than as a separate CREATE INDEX.
...
Is there any problem
At 15:50 22/11/00 +0800, Christopher Kings-Lynne wrote:
I've been examining the pg_dump source and output, and I've come to the
conclusion that I can modify it so that UNIQUE constraints
appear as part of
the CREATE TABLE statement, rather than as a separate CREATE INDEX.
...
Is there any
At 16:33 22/11/00 +0800, Christopher Kings-Lynne wrote:
At 15:50 22/11/00 +0800, Christopher Kings-Lynne wrote:
I've been examining the pg_dump source and output, and I've come to the
conclusion that I can modify it so that UNIQUE constraints
appear as part of
the CREATE TABLE statement,
At 16:33 22/11/00 +0800, Christopher Kings-Lynne wrote:
At 15:50 22/11/00 +0800, Christopher Kings-Lynne wrote:
I've been examining the pg_dump source and output, and I've come to the
conclusion that I can modify it so that UNIQUE constraints
appear as part of
the CREATE TABLE
Bruce Momjian [EMAIL PROTECTED] writes:
I have a good reason not to use UNIQUE. As I remember, pg_dump creates
the tables, copies in the data, then creates the indexes. This is much
faster than doing the copy with the indexes already created.
Right, that's the real implementation reason for
I said:
But it seems to me that it'd be really whizzy if there were two
different styles of output, one for a full dump (CREATE, load data,
add constraints) and one for schema-only dumps that tries to reproduce
the original table declaration with embedded constraint specs. That
would be
The answer to that of course is that cross-table constraints (like
REFERENCES clauses) must be disabled while loading the data, or the
intermediate states where only some tables have been loaded are likely
to fail. So we do need some kind of DISABLE CONSTRAINT mode to make
this work. But
Bruce Momjian [EMAIL PROTECTED] writes:
Why can't COPY recognize for itself that rebuilding the indexes after
loading data is a better strategy than incremental index update?
(The simplest implementation would restrict this to happen only if the
table is empty when COPY starts, which'd be
My feeling is "Let's walk before we run." We need psql \dt to show
primary/foreign keys and SERIAL first.
Bruce Momjian [EMAIL PROTECTED] writes:
Why can't COPY recognize for itself that rebuilding the indexes after
loading data is a better strategy than incremental index update?
(The
At 11:34 22/11/00 -0500, Tom Lane wrote:
full CREATE TABLE with all constraints shown
ALTER TABLE DISABLE CONSTRAINTS
I think you need something more like:
SET ALL CONSTRAINTS DISABLED/OFF
since disabling one tables constraints won't work when we have
subselect-in-check (or
Just a quick question regarding the pg_dump program:
I notice that PRIMARY KEY constraints are currently dumped as:
PRIMARY KEY ("field")
Whereas (to be in line with all the other constraints), it should be dumped
as:
CONSTRAINT "name" PRIMARY KEY ("field")
Otherwise, some poor bugger who
11 matches
Mail list logo
