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