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

From: Kyotaro HORIGUCHI <horiguchi(dot)kyotaro(at)lab(dot)ntt(dot)co(dot)jp>
To: pavel(dot)stehule(at)gmail(dot)com
Cc: masao(dot)fujii(at)gmail(dot)com, tgl(at)sss(dot)pgh(dot)pa(dot)us, oleksandr(dot)shulgin(at)zalando(dot)de, josh(at)agliodbs(dot)com, robertmhaas(at)gmail(dot)com, pgsql-hackers(at)postgresql(dot)org
Subject: Re: pg_dump quietly ignore missing tables - is it bug?
Date: 2015-07-23 05:22:59
Message-ID: 20150723.142259.200902861.horiguchi.kyotaro@lab.ntt.co.jp
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Hello,

> > 2015-07-19 20:54 GMT+02:00 Pavel Stehule <pavel(dot)stehule(at)gmail(dot)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

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Rajeev rastogi 2015-07-23 05:31:30 Autonomous Transaction is back
Previous Message Michael Paquier 2015-07-23 05:19:46 Re: [PATCH] Reload SSL certificates on SIGHUP