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@candle.pha.pa.us            |  (610)
853-3000+  If your life is a hard drive,     |  830 Blythe Avenue +  Christ can be your backup.        |  Drexel Hill,
Pennsylvania19026