From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Simon Riggs <simon(at)2ndquadrant(dot)com> |
Cc: | pgsql-hackers(at)postgreSQL(dot)org |
Subject: | Re: Backend misfeasance for DEFAULT NULL |
Date: | 2007-10-28 18:13:04 |
Message-ID: | 2451.1193595184@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Simon Riggs <simon(at)2ndquadrant(dot)com> writes:
> Seems more like an unwanted looseness in the meaning of an ALTER
> TABLE .. INHERIT to me. I'd prefer it if we added some extra clauses to
> ALTER TABLE:
> [ { INCLUDING | EXCLUDING } { DEFAULTS | CONSTRAINTS | INDEXES } ]
I think you're confusing this with a CREATE TABLE operation.
"Excluding constraints" is not sensible in any case: failing to inherit
check constraints should be disallowed IMHO. (There's already a TODO to
add inheritance info to pg_constraint so that that can be enforced in a
more bulletproof fashion.)
The other two categories of things are explicitly allowed to be
different between a child and a parent, and so I'm not convinced that
ALTER INHERIT has any business touching them.
But even if it's decided that the above is a sensible future feature,
it's certainly not something we can do as a backpatchable bug fix.
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Gregory Stark | 2007-10-28 18:14:44 | Re: Backend misfeasance for DEFAULT NULL |
Previous Message | Simon Riggs | 2007-10-28 17:21:49 | Re: Backend misfeasance for DEFAULT NULL |