Re: [HACKERS] BUG #1290: Default value and ALTER...TYPE - Mailing list pgsql-bugs

From Tom Lane
Subject Re: [HACKERS] BUG #1290: Default value and ALTER...TYPE
Date
Msg-id 28596.1098661841@sss.pgh.pa.us
Whole thread Raw
In response to Re: [HACKERS] BUG #1290: Default value and ALTER...TYPE  (Neil Conway <neilc@samurai.com>)
List pgsql-bugs
Neil Conway <neilc@samurai.com> writes:
> On Mon, 2004-10-25 at 00:30, Tom Lane wrote:
>> 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 :)

Sure I can.  The method you propose will produce exactly the same
results as what's in there.  I am still a bit concerned about
nonintuitive results in some cases, but changing it like this wouldn't
fix that; it's just a different way of getting to the same place.

The bottom line here is what will produce the least surprise in the most
cases.  The case that actually convinced me to do it was thinking about
serial columns.  As it is now, "ALTER COLUMN TYPE bigint" will
successfully convert a serial to a bigserial; before, it wouldn't,
because the result of nextval() would still get squeezed down to int4.
        regards, tom lane


pgsql-bugs by date:

Previous
From: Neil Conway
Date:
Subject: Re: [HACKERS] BUG #1290: Default value and ALTER...TYPE
Next
From: "Scott Marlowe"
Date:
Subject: Re: [GENERAL] Question on the 8.0Beta Version