| From: | Greg Stark <gsstark(at)mit(dot)edu> |
|---|---|
| To: | Jeff Davis <pgsql(at)j-davis(dot)com> |
| Cc: | Robert Haas <robertmhaas(at)gmail(dot)com>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Peter Eisentraut <peter_e(at)gmx(dot)net>, Simon Riggs <simon(at)2ndquadrant(dot)com>, pgsql-hackers(at)postgresql(dot)org |
| Subject: | Re: operator exclusion constraints |
| Date: | 2009-11-14 18:58:30 |
| Message-ID: | 407d949e0911141058h17ca482ds97413ae8acd0bb95@mail.gmail.com |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
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.
--
greg
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Andrew Dunstan | 2009-11-14 19:06:40 | Re: Inspection of row types in pl/pgsql and pl/sql |
| Previous Message | Tom Lane | 2009-11-14 18:45:54 | Re: Inspection of row types in pl/pgsql and pl/sql |