Re: pg_dump quietly ignore missing tables - is it bug?

From: Pavel Stehule <pavel(dot)stehule(at)gmail(dot)com>
To: Josh Berkus <josh(at)agliodbs(dot)com>
Cc: Robert Haas <robertmhaas(at)gmail(dot)com>, PostgreSQL Hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: pg_dump quietly ignore missing tables - is it bug?
Date: 2015-03-14 23:55:46
Message-ID: CAFj8pRAw-O=ALPsDJzRuJ3bx0xKn3xHOo+aeDdCSG3qE17jkZw@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

2015-03-14 19:33 GMT+01:00 Pavel Stehule <pavel(dot)stehule(at)gmail(dot)com>:

>
>
> 2015-03-13 23:43 GMT+01:00 Josh Berkus <josh(at)agliodbs(dot)com>:
>
>> On 03/13/2015 10:01 AM, Pavel Stehule wrote:
>> >
>> >
>> > 2015-03-13 17:39 GMT+01:00 Robert Haas <robertmhaas(at)gmail(dot)com
>> > <mailto:robertmhaas(at)gmail(dot)com>>:
>> >
>> > On Fri, Mar 13, 2015 at 11:26 AM, Pavel Stehule
>> > <pavel(dot)stehule(at)gmail(dot)com <mailto:pavel(dot)stehule(at)gmail(dot)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(at)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?
>>
>
> We can use a same rules like we use for STRICT clause somewhere. There
> should be only one table specified by the option. If it is not necessary,
> then only name is enough, else qualified name is necessary.
>
> what is a name for this option? Maybe only with long name - some like
> 'required-table' ?
>

other variant, I hope better than previous. We can introduce new long
option "--strict". With this active option, every pattern specified by -t
option have to have identifies exactly only one table. It can be used for
any other "should to exists" patterns - schemas. Initial implementation in
attachment.

Regards

Pavel

>
> Regards
>
> Pavel
>
>
>>
>> --
>> Josh Berkus
>> PostgreSQL Experts Inc.
>> http://pgexperts.com
>>
>
>

Attachment Content-Type Size
pg_dump.patch text/x-patch 5.4 KB

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Kouhei Kaigai 2015-03-15 02:37:48 Re: Custom/Foreign-Join-APIs (Re: [v9.5] Custom Plan API)
Previous Message Tom Lane 2015-03-14 22:04:46 Faster setup_param_list() in plpgsql