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

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.

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