On Mon, 2011-01-31 at 11:24 -0500, Robert Haas wrote:
> On Mon, Jan 31, 2011 at 10:31 AM, Kevin Grittner
> <Kevin.Grittner@wicourts.gov> wrote:
> > Bruce Momjian <bruce@momjian.us> wrote:
> >> As a novice I am not sure why we _wouldn't_ create two new
> >> separate error codes
> >
> > The argument for using SQLSTATE 40001 for failures which are
> > strictly due to concurrency problems, and are likely to work if the
> > transaction is retried, is that there is already a lot of software
> > which knows how to do that. On the other hand, going into such code
> > to turn that into a list of concurrency failure states is probably
> > only going to cause pain to those with applications intended to work
> > with multiple DBMS products without much modification.
>
> Yeah, I think that one's pretty logical.
> I think my vote is to either
> change the drop-database case to be the same as that
No, we shouldn't have a "can retry" errcode for a "must not retry" case.
> , or to use a new
> error code. ERRCODE_ADMIN_SHUTDOWN is just strange.
It's not strange at all. It's the same error code as we use for all of
the other cases listed. We need that because it is the current
catch-all errcode for "cannot retry".
The purpose of errcodes is to allow programs to check them and then act.
It's pointless to add a new errcode that is so rare that nobody will
ever program for it because they won't expect it, let alone test for it.
Or at least won't assign any sensible priority to handling that error.
-- Simon Riggs http://www.2ndQuadrant.com/books/PostgreSQL Development, 24x7 Support, Training and Services
