Re: [PATCHES] system catalog relation of a table and a serial sequence - Mailing list pgsql-hackers

From Brent Verner
Subject Re: [PATCHES] system catalog relation of a table and a serial sequence
Date
Msg-id 20020101230152.GA3069@rcfile.org
Whole thread Raw
In response to Re: [PATCHES] system catalog relation of a table and a serial sequence  (Brent Verner <brent@rcfile.org>)
Responses Re: [PATCHES] system catalog relation of a table and a serial  (Bruce Momjian <pgman@candle.pha.pa.us>)
List pgsql-hackers
[2001-12-17 09:48] Brent Verner said:
| [2001-12-16 23:23] Peter Eisentraut said:
| | Tom Lane writes:
| | 
| | > I think it'd be a bit surprising if "pg_dump -t table" would dump
| | > sequences declared independently of the table.  An example where you'd
| | > likely not be happy with that is if the same sequence is being used to
| | > feed multiple tables.
| | >
| | > I agree that dumping all such sequences will often be the desired
| | > behavior, but that doesn't leave me convinced that it's the right
| | > thing to do.
| | >
| | > Any comments out there?
| | 
| | The more general question is:  Should 'pg_dump -t table' dump all objects
| | that "table" depends on?  Keep in mind that this could mean you have to
| | dump the entire database (think foreign keys).  In my mind, dumping an
| | arbitrary subset of dependencies is not a proper solution, though.
| 
| Do you care to share your ideas on what a proper solution /would/ be?
| 
|   I agree wholly with you that it is worse to dump the "arbitrary 
| subset" of related objects along with a table.
| 
|   Assuming that 'pg_dump $ARGS db_1 > psql db_2' should never fail, 
| we must either dump only table schema for ARGS="-t table" or dump 
| /all/ dependencies for the same ARGS.
|   
|   Clearly, we are not in a position to dump all dependencies right now.
| Can we make the change that '-t table' is limited to dumping schema?
 We need to have some new command line args to allow the user to 
choose their desired behavior.  I have a patch for pg_dump that adds:

-k, --serial-sequences   when dumping schema for a single table, output                        CREATE SEQUENCE
statementsand setval() function                        calls for SERIAL columns in the table
 
-K, --all-sequences      when dumping schema for a single table, output                        CREATE SEQUENCE
statementsand setval() function                        calls for ALL sequences referenced in any DEFAULT
       column definition in the table
 
 By default, no sequence statements are dumped when using the
'-t table' switch to address the real concern that we can't practically
dump /all/ dependencies on a single table (this late in beta).  In 
order to deal with the case where multiple tables are feeding from the
sequence, a safer setval() call will be made so the nextval will never
be set to a lower value.  This is intended to setval such that 
subsequent inserts into tables feeding off a(n already existing) 
sequence will never fail due to duplicate values.  
 To determine if a sequence is a serial, I am testing if the seq
name ends with "_seq".  When '-K' is used, I'm grabbing all sequences
referenced in any nextval(..) DEFAULT definitions on the table. 
Sample output is below.  If anyone is interested in trying this patch,
you may fetch it from  http://rcfile.org/posthack/pg_dump.diff.3
 There is still a problem where using '-c' might drop a shared 
sequence when dumping a table feeding from it.  I also just thought
that it might be safer to dump all referenced sequences when using
'-s -t table'.

comments?  advice?

thanks, b


brent$ ./pg_dump -d -K -t t2 brent
-- [comments removed]

CREATE SEQUENCE "shared_sequence" start 1 increment 1 maxvalue 9223372036854775807 minvalue 1 cache 1;

CREATE SEQUENCE "t2_a_seq" start 1 increment 1 maxvalue 9223372036854775807 minvalue 1 cache 1;

CREATE TABLE "t2" ( "a" integer DEFAULT nextval('"t2_a_seq"'::text) NOT NULL, "b" integer DEFAULT
nextval('shared_sequence'::text)NOT NULL
 
);

INSERT INTO "t2" VALUES (1,25);
INSERT INTO "t2" VALUES (2,26);
INSERT INTO "t2" VALUES (3,27);
INSERT INTO "t2" VALUES (4,28);
INSERT INTO "t2" VALUES (5,29);

CREATE UNIQUE INDEX t2_a_key ON t2 USING btree (a);

SELECT setval ('"shared_sequence"', (SELECT CASE          WHEN 29 > nextval('"shared_sequence"')         THEN 29
ELSE (currval('"shared_sequence"') - 1)         END),     true);
 

SELECT setval ('"t2_a_seq"', (SELECT CASE          WHEN 5 > nextval('"t2_a_seq"')         THEN 5         ELSE
(currval('"t2_a_seq"')- 1)         END),     true);
 


-- 
"Develop your talent, man, and leave the world something. Records are 
really gifts from people. To think that an artist would love you enough
to share his music with anyone is a beautiful thing."  -- Duane Allman


pgsql-hackers by date:

Previous
From: Bruce Momjian
Date:
Subject: Re: Duplicate-key-detection failure case found in btree
Next
From: Barry Lind
Date:
Subject: problems with new vacuum (??)