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

Re: BUG #4957: search_path and pg_dump -T switch

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: "Maxim(dot)Boguk" <maxim(dot)boguk(at)gmail(dot)com>
Cc: pgsql-bugs(at)postgresql(dot)org
Subject: Re: BUG #4957: search_path and pg_dump -T switch
Date: 2009-07-31 13:59:43
Message-ID: (view raw, whole thread or download thread mbox)
Lists: pgsql-bugs
"Maxim.Boguk" <maxim(dot)boguk(at)gmail(dot)com> writes:
> Now we have table test1 with one row outside of search_path and table test2
> with one row inside of search path.

> Now 
> pg_dump -F p -D -T test1 -a test_db | grep test1
> will out:
> INSERT INTO test1 (id) VALUES (1);

> And
> pg_dump -F p -D -T test2 -a test_db | grep test2
> will out empty.

> First result is wrong.

No, I don't believe it is.  The switch means "don't dump the table named
test1 as found in your search path".  So in this case it doesn't do
anything.  You could do "-T test.test1" or "-T *.test1" if you want to
suppress that table.

We could have pg_dump throw an error if -t or -T doesn't seem to refer
to any actual table, but I'm not sure that would make it more useful.
Particularly not with wild-card-pattern switches.

			regards, tom lane

In response to

pgsql-bugs by date

Next:From: Tom LaneDate: 2009-07-31 14:09:41
Subject: Re: BUG #4956: Array Construct array() returning blank result
Previous:From: Maxim.BogukDate: 2009-07-31 10:31:52
Subject: BUG #4957: search_path and pg_dump -T switch

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