From: | "Mikheev, Vadim" <vmikheev(at)SECTORBASE(dot)COM> |
---|---|
To: | "'Tom Lane'" <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Philip Warner <pjw(at)rhyme(dot)com(dot)au> |
Cc: | "'pgsql-hackers(at)postgresql(dot)org'" <pgsql-hackers(at)postgresql(dot)org> |
Subject: | RE: Logging for sequences |
Date: | 2000-12-06 21:18:25 |
Message-ID: | 8F4C99C66D04D4118F580090272A7A234D31D2@sectorbase1.sectorbase.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
> Vadim, Philip changed that part of pg_dump on my advice. The idea was
> to try to do the right thing for sequences when loading schema only or
> data only. Analogously to loading data into a pre-existing table, we
> felt that a data dump ought to be able to restore the current state of
> an already-existing sequence object. Hence it should use setval().
Tables have many records but sequences single one.
So, I don't see what would be wrong if we would drop/recreate sequences
in data-only mode - result would be the same as with setval: required
state of sequence. Ok, ok - sequence' OID would be different.
...
> My inclination is to leave pg_dump as it stands, and change
> do_setval's error check. We could rip out the check entirely, or we
> could modify the code so that a setval() is allowed for a sequence
> with cache > 1 only if it's the new three-parameter form of setval().
> That would allow pg_dump to do its thing without changing the behavior
> for existing applications. Also, we can certainly make setval() flush
> any cached nextval assignments that the current backend is holding, even
> though we have no easy way to clean out cached values in other backends.
>
> Comments?
I don't object any approach.
Vadim
From | Date | Subject | |
---|---|---|---|
Next Message | Randy Jonasz | 2000-12-06 22:09:31 | RFC C++ Interface |
Previous Message | Tom Lane | 2000-12-06 21:12:42 | Re: Logging for sequences |