Re: pg_dump future problem. - Mailing list pgsql-hackers

From Philip Warner
Subject Re: pg_dump future problem.
Date
Msg-id 5.1.0.14.0.20030504174709.068f0840@mail.rhyme.com.au
Whole thread Raw
In response to Re: pg_dump future problem.  (Christopher Kings-Lynne <chriskl@familyhealth.com.au>)
Responses Re: pg_dump future problem.  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-hackers
At 01:49 PM 4/05/2003 +0800, Christopher Kings-Lynne wrote:
>No, 7.3 release dumps tables like this.

Good point. I had not even noticed, but I had noticed something odd in the 
last few dumps.

My preference for a solution to this problem would be to remove even more 
implementation knowledge from pg_dump, and add a command like:
    alter table really_long_name set next a = <next sequence value>;

Assuming this kind of approach is acceptable, I'm even volunteering to do 
it since it seems small and hits a few areas I have not had a chance to 
break yet. Unless of course someone else is already in the relevant areas.

It has the advantage of bypassing the problem and, if we ever redesign 
sequences, there is no impact on pg_dump.







----------------------------------------------------------------
Philip Warner                    |     __---_____
Albatross Consulting Pty. Ltd.   |----/       -  \
(A.B.N. 75 008 659 498)          |          /(@)   ______---_
Tel: (+61) 0500 83 82 81         |                 _________  \
Fax: (+61) 03 5330 3172          |                 ___________ |
Http://www.rhyme.com.au          |                /           \|                                 |    --________--
PGP key available upon request,  |  /
and from pgp5.ai.mit.edu:11371   |/



pgsql-hackers by date:

Previous
From: Christopher Kings-Lynne
Date:
Subject: Re: pg_dump future problem.
Next
From: Philip Warner
Date:
Subject: Re: Cast and Schemas don't work as expected