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

2015-07-19 21:08 GMT+02:00 Pavel Stehule <pavel(dot)stehule(at)gmail(dot)com>:

>
>
> 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).
>

Note: originally I though, we have to fix it and change the default behave.
But with special option, we don't need it. This option in help is signal
for user, so some is risky.

Pavel

>
>
>
>>
>> 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
>>>>
>>>
>>>
>>
>