Skip site navigation (1) Skip section navigation (2)

Re: Hm, table constraints aren't so unique as all that

From: "David Rowley" <dgrowleyml(at)gmail(dot)com>
To: "'Tom Lane'" <tgl(at)sss(dot)pgh(dot)pa(dot)us>,"'Peter Geoghegan'" <peter(dot)geoghegan86(at)gmail(dot)com>
Cc: <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Hm, table constraints aren't so unique as all that
Date: 2013-01-29 05:01:47
Message-ID: 000b01cdfddd$c08788c0$41969a40$ (view raw, whole thread or download thread mbox)
Lists: pgsql-hackers
> Tom Lane Wrote:
> Peter Geoghegan <peter(dot)geoghegan86(at)gmail(dot)com> writes:
> > On 29 January 2013 00:25, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> > I can see the case for fixing this, but I don't feel that it's
> > particularly important that constraints be uniquely identifiable from
> > the proposed new errdata fields.
> I think that we'll soon be buried in gripes if they're not.  Pretty much
> whole point of this patch is to allow applications to get rid of ad-hoc,
> usually-works coding techniques.  I'd argue that not checking the entire
> constraint identity is about as fragile as trying to "sed"
> the constraint name out of a potentially-localized error message.
> In both cases, it often works fine, until the application's context

+1 here too. I'm feel I'm quite close to the front of the queue of
application developers waiting on enhances error fields. I'd personally
rather I noticed my application was broken during an testing an upgrade to
9.3 than somewhere down the line. I can't imagine renaming a constraint to
upgrade to 9.3 is going to be a showstopper for anyone.

Perhaps the release notes can contain a query to allow users to check this

David Rowley

> 			regards, tom lane
> --

In response to

pgsql-hackers by date

Next:From: Josh BerkusDate: 2013-01-29 05:09:52
Subject: Re: autovacuum not prioritising for-wraparound tables
Previous:From: Tom LaneDate: 2013-01-29 04:08:33
Subject: Re: enhanced error fields

Privacy Policy | About PostgreSQL
Copyright © 1996-2018 The PostgreSQL Global Development Group