From: | Greg Stark <gsstark(at)mit(dot)edu> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | Greg Stark <gsstark(at)mit(dot)edu>, Hannu Krosing <hannu(at)skype(dot)net>, Zeugswetter Andreas DCP SD <ZeugswetterA(at)spardat(dot)at>, pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: ADD/DROP INHERITS |
Date: | 2006-06-08 16:34:09 |
Message-ID: | 871wtzli7y.fsf@stark.xeocode.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> writes:
> Greg Stark <gsstark(at)mit(dot)edu> writes:
> > Come to think of it it's pretty strange that you can drop an inherited
> > constraint from a child. And doing an experiment it seems you can also DROP
> > NOT NULL on a child which is also pretty strange.
>
> Yeah. I think we had agreed that this is a bug. Note the TODO entries:
Ok, so it's definitely correct for me to require that new children have NOT
NULL if their parent has NOT NULL.
> > I don't see how to block these operations though unless we either search
> > parent classes for constraints to check at run-time or add additional
> > dependency records to block dropping these things.
>
> The implementation I had in mind was to add columns similar to attinhcount
> and attislocal to pg_constraint.
Hm that would be simpler. That still leaves NOT NULL as a bit of a headache.
--
greg
From | Date | Subject | |
---|---|---|---|
Next Message | Andrew Dunstan | 2006-06-08 16:34:54 | Re: [HACKERS] drop if exists remainder |
Previous Message | Alvaro Herrera | 2006-06-08 16:30:27 | Re: ADD/DROP INHERITS |