Thread: Dump Version
Hello, dump problems again. I'm working on a dump ToC parser for spatial database restore (postgis). I've noticed that pg_dump-7.3 and pg_dump-7.4 list CAST entries in different ways. Still 'Dump Version' is the same (1.7-0). What does 'Dump Version' refer to then ? Are these ToC output changes encoded somehow ? TIA --strk;
At 08:09 PM 13/08/2004, strk wrote: >What does 'Dump Version' refer to then ? Are these ToC output >changes encoded somehow ? The file format version of pg_dump; the actual contents depend on pg_dump version, and the source database since pg_dump asks the source (as much as possible) to present it's data in a textual format. What are you trying to do? ---------------------------------------------------------------- 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 pgp.mit.edu:11371 |/
On Fri, Aug 13, 2004 at 08:42:44PM +1000, Philip Warner wrote: > At 08:09 PM 13/08/2004, strk wrote: > >What does 'Dump Version' refer to then ? Are these ToC output > >changes encoded somehow ? > > The file format version of pg_dump; the actual contents depend on pg_dump > version, and the source database since pg_dump asks the source (as much as > possible) to present it's data in a textual format. > > What are you trying to do? Commenting out lines from the dump corresponding to objects that will be defined by another script. I also had problem with OPERATOR as only the name is listed (I parsed the ascii version as a workaround). I can parse the ascii version for CASTS as well... but I if everything was possible just using the ToC that would be faster. --strk; > > > ---------------------------------------------------------------- > 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 pgp.mit.edu:11371 |/
At 08:53 PM 13/08/2004, strk wrote:
>Commenting out lines from the dump corresponding to objects that
>will be defined by another script.
I may have misunderstood, but try:
pg_restore -l dumpfile > listfile
then delete lines from listfile that you do not want, and do:
pg_restore -L listfile dumpfile
and it will only restore the items corresponding to lines in listfile.
----------------------------------------------------------------
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 pgp.mit.edu:11371 |/
Philip, I'm trying to make the process you describe automatic. A script reads objects definitoin from an .sql file and automatically deletes linkes from 'listfile' corresponding to objects already found in the given .sql file. As for my problem (detecting CASTS) I had to support lines in the form: From PG73:552; 2663984 CAST bytea (public.wkb) From PG74:547; 1915318 CAST CAST (public.wkb AS bytea) Since these two dumps have same file format version I asked.. --strk; On Fri, Aug 13, 2004 at 10:05:09PM +1000, Philip Warner wrote: > At 08:53 PM 13/08/2004, strk wrote: > >Commenting out lines from the dump corresponding to objects that > >will be defined by another script. > > I may have misunderstood, but try: > > pg_restore -l dumpfile > listfile > > then delete lines from listfile that you do not want, and do: > > pg_restore -L listfile dumpfile > > and it will only restore the items corresponding to lines in listfile. > > > > > > ---------------------------------------------------------------- > 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 pgp.mit.edu:11371 |/
At 10:30 PM 13/08/2004, strk wrote:
> >From PG73:
> 552; 2663984 CAST bytea (public.wkb)
> >From PG74:
> 547; 1915318 CAST CAST (public.wkb AS bytea)
>
>Since these two dumps have same file format version I asked..
The file format (unfortunately for you) does not define the format of the
contents of the TOC entries. It may be messy, but you could use your source
sql file to create an empty database in the same PG version, then do:
pg_dump -Fc tempdatabase | pg_restore -l
to get a compatible list. But you'll still have mismatched OIDs, and a temp
database to create/cleanup.
I can't see another way that won't require constant updates & tweaking into
the future.
----------------------------------------------------------------
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 pgp.mit.edu:11371 |/
On Fri, Aug 13, 2004 at 11:12:50PM +1000, Philip Warner wrote: > At 10:30 PM 13/08/2004, strk wrote: > >>From PG73: > > 552; 2663984 CAST bytea (public.wkb) > >>From PG74: > > 547; 1915318 CAST CAST (public.wkb AS bytea) > > > >Since these two dumps have same file format version I asked.. > > The file format (unfortunately for you) does not define the format of the > contents of the TOC entries. Ok. This is what I wanted to know. Thank you. --strk;