Re: operator exclusion constraints

Поиск
Список
Период
Сортировка
От Greg Stark
Тема Re: operator exclusion constraints
Дата
Msg-id 407d949e0911141058h17ca482ds97413ae8acd0bb95@mail.gmail.com
обсуждение исходный текст
Ответ на Re: operator exclusion constraints  (Jeff Davis <pgsql@j-davis.com>)
Ответы Re: operator exclusion constraints
Список pgsql-hackers
On Sat, Nov 14, 2009 at 6:00 PM, Jeff Davis <pgsql@j-davis.com> wrote:
> Hopefully the user never sees that message -- it's almost an Assert.
> PostgreSQL uses elog(ERROR,...) in many places that should be
> unreachable, but might happen due to bugs in distant places or
> corruption. I'm not sure the exact convention there, but I figure that
> some details are appropriate.

Yeah, I think that's right. I think part of the rationale is that if
the admin mucks around with catalog tables or does some DDL with
inconsistent definitions (like an operator class that isn't internally
consistent for example) then we don't treat those errors as
user-visible errors that need to be translated but they shouldn't
cause a database crash either.

If it's possible for the case to arrive through users doing things
through entirely supported means then they might need to be real
ereports(). But I guess there are grey areas.

-- 
greg


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

Предыдущее
От: Tom Lane
Дата:
Сообщение: Re: Inspection of row types in pl/pgsql and pl/sql
Следующее
От: Andrew Dunstan
Дата:
Сообщение: Re: Inspection of row types in pl/pgsql and pl/sql