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
