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