Re: enhanced error fields

From: Peter Geoghegan <peter(at)2ndquadrant(dot)com>
To: Stephen Frost <sfrost(at)snowman(dot)net>
Cc: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Pavel Stehule <pavel(dot)stehule(at)gmail(dot)com>, PostgreSQL Hackers <pgsql-hackers(at)postgresql(dot)org>, Alvaro Herrera <alvherre(at)commandprompt(dot)com>
Subject: Re: enhanced error fields
Date: 2012-12-29 23:29:52
Message-ID: CAEYLb_X8+hQqPW2vUBP=htUTP8KTgOkCOG+s59shvrEfdOpq-g@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On 29 December 2012 22:57, Stephen Frost <sfrost(at)snowman(dot)net> wrote:
> So they'll quickly realize that a lookup-table based on constraint name
> would be useful, create it, and then have a primary key on it to make
> sure that they don't have any duplicates.

I don't find that terribly likely. There is nothing broken about the
example. It's possible to misuse almost anything.

In order for the problem you describe to happen, the user would have
to ignore the warning in the documentation about constraint_name's
ability to uniquely identify something, and then have two constraints
in play at the same time with the same name but substantively
different. That seems incredibly unlikely.

Maybe you think that users cannot be trusted to take that warning on
board, but then the same user could not be trusted to heed another
warning about using a constraint_schema in the lookup table primary
key.

This whole lookup table idea presupposes that there'll only ever be
one error message per constraint in the entire application. That
usually isn't true for all sorts of reasons, in my experience.

--
Peter Geoghegan http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training and Services

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Stephen Frost 2012-12-30 02:01:04 Re: enhanced error fields
Previous Message Stephen Frost 2012-12-29 22:57:04 Re: enhanced error fields