Re: [HACKERS] DEFAULT fixed

Added to TODO:

* CREATE TABLE test (a char(5) DEFAULT text '', b int4) fails on INSERT

> Actually, it's not as fixed as all that...
>
> create table foo1 (a char(5) default '', b int4);
> insert into foo1 (b) values (334);
> select * from foo1;
> a | b
> -----+---
> |334
> (1 row)
>
> Good, the basic case is fixed, but:
>
> create table foo2 (a char(5) default text '', b int4);
> insert into foo2 (b) values (334);
> select * from foo2;
> a| b
> -+--
> |16
> (1 row)
>
> Ooops.
>
> What you seem to have done is twiddle the handling of DEFAULT clauses
> so that the value stored for the default expression is pre-coerced to the
> column type. That's good as far as it goes, but it fails in cases where
> the stored value has to be of a different type.
>
> My guess is that what *really* ought to happen here is that
> transformInsertStmt should check the type of the value it's gotten from
> the default clause and apply coerce_type if necessary.
>
> Unless someone can come up with a less artificial example than the one
> above, I'm inclined to leave it alone for 6.5. This is the same code
> area that will have to be redone to fix the INSERT ... SELECT problem
> I was chasing earlier today: coercion of the values produced by SELECT
> will have to wait until the tail end of transformInsertStmt, and we
> might as well make wrong-type default constants get fixed in the same
> place. So I'm not eager to write some throwaway code to patch a problem
> that no one is likely to see in practice. What's your feeling about it?
>
> regards, tom lane
>

--
Bruce Momjian | http://www.op.net/~candle
maillist(at)candle(dot)pha(dot)pa(dot)us | (610) 853-3000
+ If your life is a hard drive, | 830 Blythe Avenue
+ Christ can be your backup. | Drexel Hill, Pennsylvania 19026