Re: Backend misfeasance for DEFAULT NULL - Mailing list pgsql-hackers

From Tom Lane
Subject Re: Backend misfeasance for DEFAULT NULL
Date
Msg-id 2451.1193595184@sss.pgh.pa.us
Whole thread Raw
In response to Re: Backend misfeasance for DEFAULT NULL  (Simon Riggs <simon@2ndquadrant.com>)
List pgsql-hackers
Simon Riggs <simon@2ndquadrant.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


pgsql-hackers by date:

Previous
From: Simon Riggs
Date:
Subject: Re: Backend misfeasance for DEFAULT NULL
Next
From: Gregory Stark
Date:
Subject: Re: Backend misfeasance for DEFAULT NULL