Re: operator exclusion constraints

On Sat, Nov 14, 2009 at 1:58 PM, Greg Stark <gsstark(at)mit(dot)edu> wrote:
> On Sat, Nov 14, 2009 at 6:00 PM, Jeff Davis <pgsql(at)j-davis(dot)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.

I guess my point wasn't that the message was likely to be exercised,
but rather that it isn't obvious that it's describing an error
condition at all. If you get this message:

relation "whatever" has relopxconstraints = -3

...you can't even tell that it's an error message unless it happens to
be preceded by "ERROR: ". If you get something like:

relation "whatever" has invalid relopxconstraints value (-3)

...it's much more clear that this is not just informational.

...Robert