Re: pg_dump quietly ignore missing tables - is it bug?

Sorry for the bogus on bogus.

At Thu, 23 Jul 2015 14:22:59 +0900 (Tokyo Standard Time), Kyotaro HORIGUCHI <horiguchi.kyotaro@lab.ntt.co.jp> wrote in
<20150723.142259.200902861.horiguchi.kyotaro@lab.ntt.co.jp>
> Hello,
> 
> > > 2015-07-19 20:54 GMT+02:00 Pavel Stehule <pavel.stehule@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