Re: [HACKERS] BUG #1290: Default value and ALTER...TYPE

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Rod Taylor <pg(at)rbt(dot)ca>
Cc: Troels Arvin <troels(at)arvin(dot)dk>, pgsql-bugs(at)postgresql(dot)org, PostgreSQL Development <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: [HACKERS] BUG #1290: Default value and ALTER...TYPE
Date: 2004-10-21 04:19:38
Message-ID: 11275.1098332378@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-bugs pgsql-hackers

Rod Taylor <pg(at)rbt(dot)ca> writes:
> On Wed, 2004-10-20 at 14:07, Tom Lane wrote:
>> "PostgreSQL Bugs List" <pgsql-bugs(at)postgresql(dot)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

In response to

Browse pgsql-bugs by date

  From Date Subject
Next Message Federico Fissore 2004-10-21 07:32:16 Re: bug 1201
Previous Message Troels Arvin 2004-10-20 18:29:12 Re: BUG #1290: Default value and ALTER...TYPE

Browse pgsql-hackers by date

  From Date Subject
Next Message ronzo 2004-10-21 10:44:33 Postresql 8.0 Beta 3 - SELECT ... FOR UPDATE
Previous Message Philip Warner 2004-10-21 01:08:05 Re: Using ALTER TABLESPACE in pg_dump