From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | SQLpro <sqlpro(at)sqlspot(dot)com> |
Cc: | pgsql-bugs(at)postgresql(dot)org |
Subject: | Re: Primary key error in INFORMATION_SCHEMA views |
Date: | 2018-05-23 20:39:47 |
Message-ID: | 8886.1527107987@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-bugs |
SQLpro <sqlpro(at)sqlspot(dot)com> writes:
> The Following script demonstrate the bug:
> CREATE SCHEMA s;
> CREATE TABLE s.foo (C INT);
> ALTER TABLE s.foo ADD CONSTRAINT k CHECK(C>0);
> CREATE TABLE s.foo2 (C INT);
> ALTER TABLE s.foo2 ADD CONSTRAINT k CHECK(C>=1);
> This last SQL command should fail because the database name, the schema name
> and the constraint name is the same for those two constraints, but did'nt !
Indeed, but Postgres does not require check constraints to be named
uniquely across the whole schema, only per-table. Tightening that would
be a cure worse than the disease, because it would break applications
that work today.
So, sorry, we do not consider this a bug, and it's highly unlikely that
we'd ever "fix" it. You're surely free to use only spec-compliant choices
of constraint names in your own databases if you wish, but PG won't
enforce that.
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Jeremy Schneider | 2018-05-23 21:20:23 | Re: BUG #14820: Standby crash with "could not access status of transaction" (for track_commit_timestamp) |
Previous Message | SQLpro | 2018-05-23 20:12:27 | Primary key error in INFORMATION_SCHEMA views |