From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Simon Riggs <simon(at)2ndquadrant(dot)com> |
Cc: | Berend Tober <btober(at)seaworthysys(dot)com>, pgsql-hackers(at)postgresql(dot)org, pgsql-general(at)postgresql(dot)org |
Subject: | Re: [HACKERS] Inherited constraints and search paths (was Re: |
Date: | 2005-05-20 15:51:46 |
Message-ID: | 25273.1116604306@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-general pgsql-hackers |
Simon Riggs <simon(at)2ndquadrant(dot)com> writes:
> Doing anything to restrict dropping of inherited constraints seems like
> wasted effort and potentially annoying anyhow.
Uh, why? Arguably the constraints are as much part of the parent table
definition as the columns themselves. If you had "check (f1 > 0)" in
the definition of a table, wouldn't you be pretty surprised to select
from it and find rows with f1 < 0?
regression=# create table parent(f1 int check (f1 > 0));
CREATE TABLE
regression=# create table child() inherits(parent);
CREATE TABLE
regression=# alter table child drop constraint parent_f1_check;
ALTER TABLE
regression=# insert into child values(-1);
INSERT 0 1
regression=# select * from parent;
f1
----
-1
(1 row)
I think a good argument can be made that the above behavior is a bug,
and that the ALTER command should have been rejected. We've gone to
great lengths to make sure you can't ALTER a child table to make it
incompatible with the parent in terms of the column names and types;
shouldn't this be true of check constraints as well?
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Duane Winner | 2005-05-20 15:54:47 | starting postgresql with pgsql password - workarounds? |
Previous Message | Kelly Burkhart | 2005-05-20 15:39:14 | Finding IP of front end |
From | Date | Subject | |
---|---|---|---|
Next Message | Bruce Momjian | 2005-05-20 15:58:44 | Re: 8.02 rpm error |
Previous Message | Ed L. | 2005-05-20 15:39:13 | Re: [GENERAL] Image storage questions |