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

2015-07-19 20:54 GMT+02:00 Pavel Stehule <pavel(dot)stehule(at)gmail(dot)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(dot)stehule(at)gmail(dot)com>:
>
>>
>>
>> 2015-07-08 5:36 GMT+02:00 Fujii Masao <masao(dot)fujii(at)gmail(dot)com>:
>>
>>> On Sat, May 23, 2015 at 1:41 AM, Pavel Stehule <pavel(dot)stehule(at)gmail(dot)com>
>>> wrote:
>>> >
>>> >
>>> > 2015-05-22 18:34 GMT+02:00 Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>:
>>> >>
>>> >> Oleksandr Shulgin <oleksandr(dot)shulgin(at)zalando(dot)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
>>>
>>
>>
>