> 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.
Gee, I didn't know you could specify the type of the default. Look at
this:
create table kk( x char(20) default bpchar '');
This is going to bypass the coerce_type, so I think this would fail too.
> 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.
Again, in my example, it will not even get coerced.
> 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?
Yes, I think we will just wait on this one, and add it to our TODO list
for the next release. We still have some big items on the list.
-- 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
