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

From Tom Lane
Subject Re: [BUGS] BUG #1290: Default value and ALTER...TYPE
Date
Msg-id 11275.1098332378@sss.pgh.pa.us
Whole thread Raw
In response to Re: [BUGS] BUG #1290: Default value and ALTER...TYPE  (Rod Taylor <pg@rbt.ca>)
List pgsql-hackers
Rod Taylor <pg@rbt.ca> writes:
> On Wed, 2004-10-20 at 14:07, Tom Lane wrote:
>> "PostgreSQL Bugs List" <pgsql-bugs@postgresql.org> writes:
>>> troels=# create table lookat_feature(
>>> troels(#   feature_id char(4),
>>> troels(#   status varchar(2) default 'TODO'

> I think the bug is that default takes a value which does not fit the
> columns data type.

You could argue that this CREATE TABLE should have failed, but I think
it's an orthogonal issue.  It's easy to think of cases where a default
expression will fail only some of the time.  For instance
mycol int2 default 100000 * random()

which might well pass muster if CREATE TABLE checks it, and yet would
fail more than half the time in use.  This is a pretty bogus example of
course, but I think that more-plausible examples could be invented
involving timestamps and now().

I think the real issue posed by Troels' example is that data values
stored within the converted column will be converted from the original
column datatype to the new type.  If we change the handling of the
default expression to avoid this failure, then the default expression
will not be converted in quite the same way.  Maybe that is a good
thing, or maybe it's not.  I'm not quite sold on either viewpoint...
        regards, tom lane


pgsql-hackers by date:

Previous
From: Philip Warner
Date:
Subject: Re: Using ALTER TABLESPACE in pg_dump
Next
From: "ronzo"
Date:
Subject: Postresql 8.0 Beta 3 - SELECT ... FOR UPDATE