From: | Neil Conway <neilc(at)samurai(dot)com> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | Troels Arvin <troels(at)arvin(dot)dk>, pgsql-bugs(at)postgresql(dot)org, pgsql-hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: [HACKERS] BUG #1290: Default value and ALTER...TYPE |
Date: | 2004-10-24 23:41:37 |
Message-ID: | 1098661296.12577.24.camel@localhost.localdomain |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-bugs pgsql-hackers |
On Mon, 2004-10-25 at 00:30, Tom Lane wrote:
> Not without an initdb (to have another column to put it in).
We're already requiring an initdb for beta4; if this is the right way to
fix this (and I'm not insisting that it is), then ISTM we can just push
back beta4 a few days.
> And it
> would produce exactly the same result anyway, because the only way there
> could be implicit coercion steps at the top of the expression is because
> step 3 put them there.
Per your earlier comment: "I am not sure that this is a good idea,
however; it seems like it might alter the semantics in
unexpected ways. (The default expression could potentially come through
differently than an actually stored value of the column would do.)"
So you can't have it both ways :)
I think it's somewhat fragile to remove the coercion by hand at ALTER
TABLE time, but as you say, I can't think of a reason why it wouldn't
work.
-Neil
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2004-10-24 23:50:41 | Re: [HACKERS] BUG #1290: Default value and ALTER...TYPE |
Previous Message | Dennis Bjorklund | 2004-10-24 15:10:37 | Re: [HACKERS] BUG #1290: Default value and ALTER...TYPE |
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2004-10-24 23:50:41 | Re: [HACKERS] BUG #1290: Default value and ALTER...TYPE |
Previous Message | Tom Lane | 2004-10-24 23:04:25 | Re: Compile error on 7.2.6/contrib/seg |