Re: pg_dump quietly ignore missing tables - is it bug?
От | Pavel Stehule |
---|---|
Тема | Re: pg_dump quietly ignore missing tables - is it bug? |
Дата | |
Msg-id | CAFj8pRAQNB730YqJOdv0uzJHOaAb++_ORH72A6s99Aqsgz+X_w@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: pg_dump quietly ignore missing tables - is it bug? (Pavel Stehule <pavel.stehule@gmail.com>) |
Ответы |
Re: pg_dump quietly ignore missing tables - is it bug?
|
Список | pgsql-hackers |
2015-03-23 17:11 GMT+01:00 Pavel Stehule <pavel.stehule@gmail.com>:
Hi2015-03-15 16:09 GMT+01:00 Tom Lane <tgl@sss.pgh.pa.us>:Pavel Stehule <pavel.stehule@gmail.com> writes:
> other variant, I hope better than previous. We can introduce new long
> option "--strict". With this active option, every pattern specified by -t
> option have to have identifies exactly only one table. It can be used for
> any other "should to exists" patterns - schemas. Initial implementation in
> attachment.
I think this design is seriously broken. If I have '-t foo*' the code
should not prevent that from matching multiple tables. What would the use
case for such a restriction be?
What would make sense to me is one or both of these ideas:
* require a match for a wildcard-free -t switch
* require at least one (not "exactly one") match for a wildcarded -t
switch.attached initial implementation
updated version - same mechanism should be used for schema
Regards
Pavel
RegardsPavel
Neither of those is what you wrote, though.
If we implemented the second one of these, it would have to be controlled
by a new switch, because there are plausible use cases for wildcards that
sometimes don't match anything (not to mention backwards compatibility).
There might be a reasonable argument for the first one being the
default behavior, though; I'm not sure if we could get away with that
from a compatibility perspective.
regards, tom lane
Вложения
В списке pgsql-hackers по дате отправления: