ncm@zembu.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);
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.
regards, tom lane