Sorry for the bogus on bogus. At Thu, 23 Jul 2015 14:22:59 +0900 (Tokyo Standard Time), Kyotaro HORIGUCHI <horiguchi.kyot...@lab.ntt.co.jp> wrote in <20150723.142259.200902861.horiguchi.kyot...@lab.ntt.co.jp> > Hello, > > > > 2015-07-19 20:54 GMT+02:00 Pavel Stehule <pavel.steh...@gmail.com>: > > >> 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). > > I share the same option with Tom that it should behave in same > way regardless of the appearance of wildcards. > > You replied Tom as this > > > the behave is same - only one real identifier is allowed > > But the description above about this patch apparently says that > they are differently handled. And > expand_(schema|table)_name_patterns does the further differently > thing from both of Tom's suggestion and what mentioned in your > reply to that. I will mention for this topic again in this mail. > > # Might "only one real ident is allowed" mean "at most one > # match", but not "exactly one match"? > > They do like this when strict-names. > > - Not allow no match for non-wildcarded names. > > - Allow no match for any wildcarded name spec and finally > allowing *all* of them don't match anyting. > > This looks to me quite confusing. > > > >> 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). > > The new name "processSQLName" looks a bit > bogus. processSQLNameIntenral would be a name commonly seen in > such cases.
The ocrrent name is not that but processSQLNamePatternInternal. > > >> 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. > > Why do you think so? Wild cards are usually used to glob multiple > names at once. One or more matches are expected for many or > perhaps most cases, I think. Since so, if someone anticipate that > some of his patterns have no match, I think he shouldn't specify > --strict-names option at all. > > Furthermore, I don't think no one wants to use both wildcarded > and non-wildcarded name specs at once but this is a little out of > scope. > > I'd like to have opinions from others about this point. > > > > other variant is using --strict-names behave as default (and implement > > > negative option like --disable-strict-names or some similar). > > This contradicts Josh's request. (which I'm not totally agree:p) > > > 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. > > regards, -- Kyotaro Horiguchi NTT Open Source Software Center -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers