1 files changed, 59 insertions, 0 deletions
diff --git a/doc/TODO.detail/default b/doc/TODO.detail/default
new file mode 100644
index 00000000000..41d6627ec42
--- /dev/null
+++ b/doc/TODO.detail/default
@@ -0,0 +1,59 @@
+From tgl@sss.pgh.pa.us Sun May 23 18:59:22 1999
+Received: from sss.sss.pgh.pa.us (sss.pgh.pa.us [206.210.65.6])
+	by candle.pha.pa.us (8.9.0/8.9.0) with ESMTP id SAA08491
+	for <maillist@candle.pha.pa.us>; Sun, 23 May 1999 18:59:21 -0400 (EDT)
+Received: from sss.sss.pgh.pa.us (localhost [127.0.0.1])
+	by sss.sss.pgh.pa.us (8.9.1/8.9.1) with ESMTP id SAA27952;
+	Sun, 23 May 1999 18:58:53 -0400 (EDT)
+To: Bruce Momjian <maillist@candle.pha.pa.us>
+cc: PostgreSQL-development <pgsql-hackers@postgreSQL.org>
+Subject: Re: [HACKERS] DEFAULT fixed 
+In-reply-to: Your message of Sat, 22 May 1999 21:12:19 -0400 (EDT) 
+             <199905230112.VAA13489@candle.pha.pa.us> 
+Date: Sun, 23 May 1999 18:58:52 -0400
+Message-ID: <27950.927500332@sss.pgh.pa.us>
+From: Tom Lane <tgl@sss.pgh.pa.us>
+Status: ROr
+
+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
+