mirror of
https://github.com/postgres/postgres.git
synced 2025-10-31 10:30:33 +03:00
60 lines
2.2 KiB
Plaintext
60 lines
2.2 KiB
Plaintext
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
|
|
|