2015-07-08 5:36 GMT+02:00 Fujii Masao <masao.fu...@gmail.com>: > On Sat, May 23, 2015 at 1:41 AM, Pavel Stehule <pavel.steh...@gmail.com> > wrote: > > > > > > 2015-05-22 18:34 GMT+02:00 Tom Lane <t...@sss.pgh.pa.us>: > >> > >> Oleksandr Shulgin <oleksandr.shul...@zalando.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 >
