From: | Pavel Stehule <pavel(dot)stehule(at)gmail(dot)com> |
---|---|
To: | Fujii Masao <masao(dot)fujii(at)gmail(dot)com> |
Cc: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Oleksandr Shulgin <oleksandr(dot)shulgin(at)zalando(dot)de>, Josh Berkus <josh(at)agliodbs(dot)com>, Robert Haas <robertmhaas(at)gmail(dot)com>, PostgreSQL Hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: pg_dump quietly ignore missing tables - is it bug? |
Date: | 2015-07-09 20:48:38 |
Message-ID: | CAFj8pRAOiRg=tn3r08CG93cqH1-9afWc5-TUuoxY5c4YZyTK_A@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
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
>
From | Date | Subject | |
---|---|---|---|
Next Message | Jeff Janes | 2015-07-09 20:49:38 | ToDo list update for BRIN indexes |
Previous Message | Pavel Stehule | 2015-07-09 20:31:12 | Re: PL/pgSQL, RAISE and error context |