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