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

Re: constraints and sql92 information_schema compliance

From: Stephan Szabo <sszabo(at)megazone(dot)bigpanda(dot)com>
To: "Clark C(dot) Evans" <cce(at)clarkevans(dot)com>
Cc: pgsql-hackers(at)postgresql(dot)org, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Subject: Re: constraints and sql92 information_schema compliance
Date: 2006-02-26 22:09:07
Message-ID: 20060226140348.X14126@megazone.bigpanda.com (view raw or flat)
Thread:
Lists: pgsql-hackers
On Sun, 26 Feb 2006, Clark C. Evans wrote:

> On Sat, Feb 25, 2006 at 10:52:48PM -0800, Stephan Szabo wrote:

> | >   * Issue a warning when creating a constraint who's name is
> | >     not unique within its (the constraint's) schema.
> |
> | I don't have a problem with it (once, I argued for following the spec
> | constraint on this way back when), however I think this was proposed and
> | rejected before as excess noise.  You might want to look back through the
> | archives.
>
> I think the problem /w the noise was that default trigger names were
> not automatically prefixed with the table name.  I'd like to see this
> warning; perhaps in the next release, the ``dump`` module can rename
> constraints like $1 and $2 to include the table name?
>
> Given that both of these issues consist of first changing the dumper and
> making an optional warning (at first) and then turning it into an error
> way down the line, could they be considered part of the same ticket?

Well, I am worried about this change idea. That's potentially going to
break applications, ALTER ... DROP CONSTRAINT and SET CONSTRAINTS both use
the constraint names.  I think maybe something like adddepend in contrib
was for 7.2 or 7.3 might be better since that makes it something that's
not automatically done but relatively easily done.

In response to

pgsql-hackers by date

Next:From: Tatsuo IshiiDate: 2006-02-26 22:31:35
Subject: Re: possible design bug with PQescapeString()
Previous:From: James William PyeDate: 2006-02-26 21:45:27
Subject: Re: Pl/Python -- current maintainer?

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