Re: operator exclusion constraints - Mailing list pgsql-hackers

From Greg Stark
Subject Re: operator exclusion constraints
Date
Msg-id 407d949e0911141058h17ca482ds97413ae8acd0bb95@mail.gmail.com
Whole thread Raw
In response to Re: operator exclusion constraints  (Jeff Davis <pgsql@j-davis.com>)
Responses Re: operator exclusion constraints
List 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 by date:

Previous
From: Tom Lane
Date:
Subject: Re: Inspection of row types in pl/pgsql and pl/sql
Next
From: Andrew Dunstan
Date:
Subject: Re: Inspection of row types in pl/pgsql and pl/sql