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

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
>