Re: Little confusing things about client_min_messages.

Поиск
Список
Период
Сортировка
От Tomonari Katsumata
Тема Re: Little confusing things about client_min_messages.
Дата
Msg-id CAC55fYcjT5MvYEk=t0rs--mRSkEBoAPoQM8bpdBfw4v5qEotxA@mail.gmail.com
обсуждение исходный текст
Ответ на Re: Little confusing things about client_min_messages.  (Tom Lane <tgl@sss.pgh.pa.us>)
Список pgsql-hackers
Hi

2014-03-10 23:45 GMT+09:00 Tom Lane <tgl@sss.pgh.pa.us>:
Tomonari Katsumata <katsumata.tomonari@po.ntts.co.jp> writes:
> Adding FATAL and PANIC to client_min_messages is done at below-commit.
> 8ac386226d76b29a9f54c26b157e04e9b8368606
> http://git.postgresql.org/gitweb/?p=postgresql.git;a=commit;h=8ac386226d76b29a9f54c26b157e04e9b8368606

> According to the commit log, it seems that the purpose
> is suppressing to be sent error message to client when "DROP TABLE".
> In those days(pre 8.1), we did not have "DROP IF EXISTS" syntax,
> so it was useful.

> If this was the reason, now(from 8.2) we have "DROP IF EXISTS" syntax,

Uh, that was one example of what it might be good for; I doubt that the
use-case has now vanished entirely.  While I'm still dubious about the
reliability of suppressing error messages, if people have been using this
type of coding for nearly 10 years then it probably works well enough
... and more to the point, they won't thank us for arbitrarily removing
it.

Maybe so.
 

I think we should leave established practice alone here.  It might be
confusing at first glance, but that doesn't mean it's the wrong thing.


I see.
If we delete it, it maybe become more confusing thing.

Thank you for your opinion.

regards,
---------------
Tomonari Katsumata

В списке pgsql-hackers по дате отправления:

Предыдущее
От: Tom Lane
Дата:
Сообщение: Re: on_exit_reset fails to clear DSM-related exit actions
Следующее
От: Amit Kapila
Дата:
Сообщение: Re: Retain dynamic shared memory segments for postmaster lifetime