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