Re: Primary key error in INFORMATION_SCHEMA views

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

In response to

Responses

Browse pgsql-bugs by date

  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