Re: Re: Changing the default value of an inherited column

On Sat, Mar 31, 2001 at 07:44:30PM -0500, Tom Lane wrote:
> ncm(at)zembu(dot)com (Nathan Myers) writes:
> >> This seems pretty random. It would be more reasonable if multiple
> >> (default) inheritance weren't allowed unless you explicitly specify a new
> >> default for the new column, but we don't have a syntax for this.
>
> > I agree, but I thought the original issue was that PG _does_ now have
> > syntax for it. Any conflict in default values should result in either
> > a failure, or "no default". Choosing a default randomly, or according
> > to an arbitrary and complicated rule (same thing), is a source of
> > bugs.
>
> Well, we *do* have a syntax for specifying a new default (the same one
> that worked pre-7.0 and does now again). I guess what you are proposing
> is the rule "If conflicting default values are inherited from multiple
> parents that each define the same column name, then an error is reported
> unless the child table redeclares the column and specifies a new default
> to override the inherited ones".
>
> That is:
>
> create table p1 (f1 int default 1);
> create table p2 (f1 int default 2);
> create table c1 (f2 float) inherits(p1, p2); # XXX
>
> would draw an error about conflicting defaults for c1.f1, but
>
> create table c1 (f1 int default 3, f2 float) inherits(p1, p2);
>
> would be accepted (and 3 would become the default for c1.f1).
>
> This would take a few more lines of code, but I'm willing to do it if
> people think it's a safer behavior than picking one of the inherited
> default values.

I do.

Allowing the line marked XXX above, but asserting no default for
c1.f1 in that case, would be equally safe. (A warning would be
polite, anyhow.) User code that doesn't rely on the default wouldn't
notice. You only need to choose a default if somebody adding rows to
c1 uses it.

Nathan Myers
ncm(at)zembu(dot)com