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