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?  (Oleksandr Shulgin <oleksandr.shulgin@zalando.de>)
Список pgsql-hackers


2015-03-23 17:11 GMT+01:00 Pavel Stehule <pavel.stehule@gmail.com>:
Hi

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

Regards

Pavel
 

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 по дате отправления:

Предыдущее
От: Michael Paquier
Дата:
Сообщение: Re: Error with index on unlogged table
Следующее
От: Andres Freund
Дата:
Сообщение: Re: Error with index on unlogged table