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

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: pgsql-hackers(at)postgresql(dot)org
Subject: Re: Re: Changing the default value of an inherited column
Date: 2001-04-02 22:26:41
Message-ID: 23978.986250401@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

ncm(at)zembu(dot)com (Nathan Myers) writes:
> On Sat, Mar 31, 2001 at 07:44:30PM -0500, Tom Lane wrote:
>> 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.

> 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.)

The trouble with that is that we don't have such a concept as "no
default", if by that you mean "INSERTs *must* specify a value".
What would really happen would be that the effective default would
be NULL, which I think would be fairly surprising behavior, since
none of the three tables involved asked for that.

I have committed code that raises an error in cases such as XXX above.
Let's try it like that for awhile and see if anyone complains ...

regards, tom lane

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Philip Warner 2001-04-03 01:57:45 Re: Re: Changing the default value of an inherited column
Previous Message Nathan Myers 2001-04-02 21:46:16 Re: Re: Changing the default value of an inherited column