Hi,
I understand (and I have read) that there have been changes and discussions
about the way, pg_dump treats SERIAL columns in the latest versions(8.x).
However, I have not been able to get a document explaining exactly what the
changes are and what's the reasoning behind it, not even in the documentation.
Is there such a thing ?
At the moment, I am kind of stuck because of this.
Here is my situation :
I have a 8.1 PG server (on Ubuntu) with my development databases. I have
created command scripts generating databases creation scripts using pg_dump, to
be able to store the db creation scripts in my source control (subversion).
I have used pg_dump 8.1.4 as it generates a script with SERIAL columns, when pg
_dump 8.2.0 generates a script with SEQUENCEs for columns created as SERIAL.
I need this to be able to maintain easily an identical Derby database.
It worked well till I created a new PG server on my laptop (to be able to work
while I was away). I decided to install a 8.2 server (to test the new version,
for the day, Ubuntu will package 8.2). And that started my problem: even
pg_dump 8.1.4 will create a script WITH SEQUENCEs (on the 8.2 server). And if
I run this script (with SEQUENCEs) on the 8.1 server to create a new db,
extracting the script with pg_dump will still generate SEQUENCEs !
(and to add to the confusion PG Admin will still show SERIAL in the colums
definition).
So my question is: can I create a script with SERIAL to be able to compare my
new database (from 8.2) with my old (8.1) db script in subversion.
Thanks for taking the time to read all this.
I hope that somebody can at least give me some pointers about pg_dump and
SERIAL.
Cheers,
[EMAIL PROTECTED]
The Computing Froggy
___________________________________________________________________________
Découvrez une nouvelle façon d'obtenir des réponses à toutes vos questions !
Profitez des connaissances, des opinions et des expériences des internautes sur
Yahoo! Questions/Réponses
http://fr.answers.yahoo.com
---------------------------(end of broadcast)---------------------------
TIP 4: Have you searched our list archives?
http://archives.postgresql.org/
