On 03/13/2015 10:01 AM, Pavel Stehule wrote: > > > 2015-03-13 17:39 GMT+01:00 Robert Haas <robertmh...@gmail.com > <mailto:robertmh...@gmail.com>>: > > On Fri, Mar 13, 2015 at 11:26 AM, Pavel Stehule > <pavel.steh...@gmail.com <mailto:pavel.steh...@gmail.com>> wrote: > > we found possible bug in pg_dump. It raise a error only when all > specified > > tables doesn't exists. When it find any table, then ignore missing > other. > > > > /usr/local/pgsql/bin/pg_dump -t Foo -t omega -s postgres > > /dev/null; echo > > $? > > > > foo doesn't exists - it creates broken backup due missing "Foo" table > > > > [pavel@localhost include]$ /usr/local/pgsql/bin/pg_dump -t Foo -t > omegaa -s > > postgres > /dev/null; echo $? > > pg_dump: No matching tables were found > > 1 > > > > Is it ok? I am thinking, so it is potentially dangerous. Any > explicitly > > specified table should to exists. > > Keep in mind that the argument to -t is a pattern, not just a table > name. I'm not sure how much that affects the calculus here, but it's > something to think about. > > > yes, it has a sense, although now, I am don't think so it was a good > idea. There should be some difference between table name and table pattern.
There was a long discussion about this when the feature was introduced in 7.3(?) IIRC. Changing it now would break backwards-compatibility, so you'd really need to introduce a new option. And, if you introduce a new option which is a specific table name, would you require a schema name or not? -- Josh Berkus PostgreSQL Experts Inc. http://pgexperts.com -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers