Re: pg_dump quietly ignore missing tables - is it bug? - Mailing list pgsql-hackers

2015-07-08 5:36 GMT+02:00 Fujii Masao <masao.fujii@gmail.com>:

On Sat, May 23, 2015 at 1:41 AM, Pavel Stehule <pavel.stehule@gmail.com> wrote:
>
>
> 2015-05-22 18:34 GMT+02:00 Tom Lane <tgl@sss.pgh.pa.us>:
>>
>> Oleksandr Shulgin <oleksandr.shulgin@zalando.de> writes:
>> > I think this is a bit over-engineered (apart from the fact that
>> > processSQLNamePattern is also used in two dozen of places in
>> > psql/describe.c and all of them must be touched for this patch to
>> > compile).
>>
>> > Also, the new --table-if-exists options seems to be doing what the old
>> > --table did, and I'm not really sure I underestand what --table does
>> > now.
>>
>> I'm pretty sure we had agreed *not* to change the default behavior of -t.
>>
>> > I propose instead to add a separate new option --strict-include, without
>> > argument, that only controls the behavior when an include pattern didn't
>> > find any table (or schema).
>>
>> If we do it as a separate option, then it necessarily changes the behavior
>> for *each* -t switch in the call.  Can anyone show a common use-case where
>> that's no good, and you need separate behavior for each of several -t
>> switches?  If not, I like the simplicity of this approach.  (Perhaps the
>> switch name could use some bikeshedding, though.)
>
>
> it is near to one proposal
>
> implement only new long option "--required-table"

There is no updated version of the patch. So I marked this patch
as "Waiting on Author".

tomorrow I'll return to this topic.

 

One very simple question is, doesn't -n option have very similar problem?
Also what about -N, -T and --exclude-table-data? Not sure if we need to
handle them in the similar way as you proposed.

hard to say - I understand to your motivation, and it can signalize some inconsistency in environment, but it has not same negative impact as same problem with -t -n options.

This is maybe place for warning message with possibility to disable this warning. But maybe it is premature optimization?

Next way is introduction of "strictness" option - default can be equivalent of current, safe can check only tables required for dump, strict can check all.

 

Isn't it sufficient to only emit the warning message to stderr if there
is no table matching the pattern specified in -t?

I prefer raising error in this case.

1. I am thinking so missing tables for dump signalize important inconsistency in environment and it is important bug

2. The warning is not simply detected (and processed) in bash scripts.

Regards

Pavel

 

Regards,

--
Fujii Masao