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
Views: Raw Message | Whole Thread | Download mbox | Resend email
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

Browse pgsql-hackers by date

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