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

2015-07-19 20:54 GMT+02:00 Pavel Stehule <pavel.stehule@gmail.com>:

Hi

I am sending updated version. It implements new long option "--strict-names". If this option is used, then for any entered name (without any wildcard char) must be found least one object. This option has not impact on patters (has wildcards chars). When this option is not used, then behave is 100% same as before (with same numbers of SQL queries for -t option). It is based on Oleksandr's documentation (and lightly modified philosophy), and cleaned my previous patch. A test on wildchard existency "strcspn(cell->val, "?*")" cannot be used, because it doesn't calculate quotes (but a replace has few lines only).

There is a possibility to remove a wildcard char test and require least one entry for patters too. But I am thinking, when somebody explicitly uses any wildcard, then he calculate with a possibility of empty result.

other variant is using --strict-names behave as default (and implement negative option like --disable-strict-names or some similar).

 

Regards

Pavel

2015-07-09 22:48 GMT+02:00 Pavel Stehule <pavel.stehule@gmail.com>:

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