From: | Fabien COELHO <coelho(at)cri(dot)ensmp(dot)fr> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | Bruce Momjian <bruce(at)momjian(dot)us>, Peter Eisentraut <peter_e(at)gmx(dot)net>, Alvaro Herrera <alvherre(at)commandprompt(dot)com>, pgsql-docs(at)postgresql(dot)org |
Subject: | Re: [BUGS] issue about information_schema REFERENTIAL_CONSTRAINTS |
Date: | 2011-02-21 08:28:15 |
Message-ID: | alpine.DEB.1.10.1102210922280.5584@cal53.paris.ensmp.fr |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-bugs pgsql-docs |
Hello,
>> When constraint names are generated by postgresql, ISTM that the software
>> is free to choose them so they could be chosen non ambiguous per schema.
>
> We do that already. See ChooseConstraintName and ChooseRelationName.
Very good news! I had not noticed that change yet. No more multiple $1
constraints then.
>> When users choose colliding names, I agree that it would break existing
>> schemas, but there could be an option to enforce uniqueness of the name
>> per schema if desired.
>
> What would be the point of that? IIRC, your complaint about this was in
> connection with wanting to write some information-schema-using code that
> could be used by anybody. Such code could hardly assume that the option
> was set.
I was thinking the other way around: the default would be "true", and
setting "false" would allow backward compatibility, if needed. In my mind,
the "if desired" was yes by default.
--
Fabien.
From | Date | Subject | |
---|---|---|---|
Next Message | Maxim Boguk | 2011-02-21 10:58:38 | Re: BUG #5798: Some weird error with pl/pgsql procedure |
Previous Message | Christopher Head | 2011-02-20 22:30:35 | BUG #5895: Ability to match more than just CN in client certificate |
From | Date | Subject | |
---|---|---|---|
Next Message | Thom Brown | 2011-02-21 10:36:53 | Re: Ambiguous index entry for Privileges |
Previous Message | Bruce Momjian | 2011-02-21 03:21:37 | Re: Ambiguous index entry for Privileges |