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

Re: constraints and sql92 information_schema compliance

From: Andrew Dunstan <andrew(at)dunslane(dot)net>
To: "Clark C(dot) Evans" <cce(at)clarkevans(dot)com>
Cc: Stephan Szabo <sszabo(at)megazone(dot)bigpanda(dot)com>, 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 21:41:08
Message-ID: 44022074.2070509@dunslane.net (view raw or flat)
Thread:
Lists: pgsql-hackers

Clark C. Evans 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?
>
>
>  
>

Ticket?  :-) You might like to read up on how our development process 
works. See http://www.postgresql.org/docs/faqs.FAQ_DEV.html

Among other things, note that we don't really have a ticket system.

More substantively, I think making an option to have pg_dump prepend the 
table name to autogenned $n type constraint names is not a bad idea.

cheers

andrew



In response to

pgsql-hackers by date

Next:From: James William PyeDate: 2006-02-26 21:45:27
Subject: Re: Pl/Python -- current maintainer?
Previous:From: Clark C. EvansDate: 2006-02-26 21:17:31
Subject: Re: constraints and sql92 information_schema compliance

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