On 03/13/2015 10:01 AM, Pavel Stehule wrote:
>
>
> 2015-03-13 17:39 GMT+01:00 Robert Haas <robertmhaas@gmail.com
> <mailto:robertmhaas@gmail.com>>:
>
> On Fri, Mar 13, 2015 at 11:26 AM, Pavel Stehule
> <pavel.stehule@gmail.com <mailto:pavel.stehule@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