2015-07-19 21:08 GMT+02:00 Pavel Stehule <pavel.steh...@gmail.com>: > > > 2015-07-19 20:54 GMT+02:00 Pavel Stehule <pavel.steh...@gmail.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.steh...@gmail.com>: >> >>> >>> >>> 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 >>>> >>> >>> >> >
