Skip site navigation (1) Skip section navigation (2)

Re: pgdump

From: Neil Conway <neilc(at)samurai(dot)com>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)us>,Andreas Joseph Krogh <andreak(at)officenet(dot)no>,Enrico <scotty(at)linuxtime(dot)it>,pgsql-hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: pgdump
Date: 2005-01-17 06:09:10
Message-ID: 1105942150.22946.46.camel@localhost.localdomain (view raw or flat)
Thread:
Lists: pgsql-hackers
On Mon, 2005-01-17 at 00:54 -0500, Tom Lane wrote:
> 	-t s1.t1
> [...] without any quoting rules it would then become impossible to
> deal with names containing dots.

Ah, yeah -- sorry, I was focusing on case conversion rather than quoting
in general.

> Are we willing to blow off that case?
> Or is it better to drop that part of the proposal?

I would be OK with just ignoring this case, but on reflection I would
prefer removing the "-t schema.table" syntax. Removing the feature
resolves the quoting issue and also simplifies pg_dump's behavior. We
lose the ability to dump table t1 in schema s1 and table t2 in schema s2
in a single command, but

(a) you can specify "-t t1 -t t2 -n s1 -n s2", although this might also
dump t1.s2 and/or t2.s1

(b) you can just run pg_dump twice, specifying the appropriate -t and -n
options each time

So the behavior would be that suggested earlier by David Skoll:

> pg_dump -t t1                          -- Dump table t1 in any schema
> pg_dump -n s1                          -- Dump all of schema s1
> pg_dump -t t1 -n s1                    -- Dump t1 in s1
> pg_dump -t t1 -t t2 -n s1              -- Dump s1.t1 and s1.t2
> pg_dump -t t1 -t t2 -n s1 -n s2        -- Dump s1.t1, s1.t2, s2.t1 and s2.t2

We'd only raise an error if we found no matching tables/schemas, as was
hashed out in July.

-Neil



In response to

Responses

pgsql-hackers by date

Next:From: Tom LaneDate: 2005-01-17 06:15:25
Subject: ARC patent
Previous:From: Tom LaneDate: 2005-01-17 05:54:22
Subject: Re: pgdump

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group