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 wen
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
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?
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
> 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. B
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
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
> 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 CREAT
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 stat
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 th
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 prob
11 matches
Mail list logo
