Forwarding this to the hackers list, since I can confirm the problem
still exists in 6.5.0. Looks like the functional extension of the
earlier problem reported with default constant values being longer
than the field. Note trhat it is causing corruption, Leon's username 
was just too short to make it visible in his example. The constant bug
is squashed, BTW: Here's my example:

test=> create table hh (dd char(2) default user, ff int4);
CREATE
test=>  insert into hh (ff) values (5);
INSERT 259723 1
test=>  select * from hh;
dd      |        ff
--------+----------
reedstrm|1836217459
(1 row)

test=> drop table hh;
DROP
test=> create table hh (dd char(2) default 'fred', ff int4);
CREATE
test=>  insert into hh (ff) values (5);
INSERT 259735 1
test=>  select * from hh;
dd|ff
--+--
fr| 5
(1 row)

test=> select version();
version                                                       
--------------------------------------------------------------
PostgreSQL 6.5.0 on i686-pc-linux-gnu, compiled by gcc 2.7.2.3
(1 row)



----- Forwarded message from Leon <leon@udmnet.ru> -----

X-From_: owner-pgsql-general@hub.org  Fri Jul 16 04:56:38 1999
Date: Fri, 16 Jul 1999 14:45:13 +0500
From: Leon <leon@udmnet.ru>
Organization: Midnight greppers corp.
X-Mailer: Mozilla 4.08 [en] (X11; I; Linux 2.2.3-5 i686)
To: "'pgsql-general@hub.org'" <pgsql-general@postgreSQL.org>
Subject: [GENERAL] Weird behavior of 'default user'
Precedence: bulk

Hello!

Look at this:

------------------
adb=> create table hh (dd char(2) default user, ff int4);
CREATE
adb=> insert into hh (ff) values (5);
INSERT 572034 1
adb=> select * from hh;
dd  |ff
----+--
leon| 5
(1 row)
------------------

How can I understand that? Column dd is of type char(2), whereas
'leon' is four characters! Even more, look here:

------------------
adb=> insert into hh  values (user, 7);
INSERT 572045 1
adb=> select * from hh;
dd  |ff
----+--
leon| 5
le  | 7
(2 rows)
------------------

This absolutely beyond my mind. This means that user, being
inserted explicitly, is correctly truncated. If it is inserted
by default, it is wider than column! Seems something very strange
is going on here.

-- 
Leon.

----- End forwarded message -----

-- 
Ross J. Reedstrom, Ph.D., <reedstrm@rice.edu> 
NSBRI Research Scientist/Programmer
Computer and Information Technology Institute
Rice University, 6100 S. Main St.,  Houston, TX 77005

Fri, 16 Jul 1999 11:32:01 -0500
"Ross J. Reedstrom" <reedstrm@wallace.ece.rice.edu>
[leon@udmnet.ru: [GENERAL] Weird behavior of 'default user']
> Forwarding this to the hackers list, since I can confirm the problem
> still exists in 6.5.0. Looks like the functional extension of the
> earlier problem reported with default constant values being longer
> than the field. Note trhat it is causing corruption, Leon's username 
> was just too short to make it visible in his example. The constant bug
> is squashed, BTW: Here's my example:

Yes, I have added this to the TODO list.  It was discovered in late 6.5,
and while the constant case was quickly fixed, the non-matching-types
case was quickly pointed out by Tom Lane, and it not fixed.

-- 
  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, Pennsylvania 19026

Fri, 16 Jul 1999 13:21:37 -0400 (EDT)
Bruce Momjian <maillist@candle.pha.pa.us>
Re: [HACKERS] [leon@udmnet.ru: [GENERAL] Weird behavior of 'default
	user']
"Ross J. Reedstrom" <reedstrm@wallace.ece.rice.edu> forwards:
> This absolutely beyond my mind. This means that user, being
> inserted explicitly, is correctly truncated. If it is inserted
> by default, it is wider than column! Seems something very strange
> is going on here.

Yes, I thought that some cases of default insertion were still broken,
and I was right.  The patch Bruce put in before only fixes the case
of a wrong-length string constant being given as the default for a
char(n) field.  When the default is not a constant, there needs to be
a run-time length coercion to char(n), and there isn't.

I have some work to do in that part of the parser anyway; will take care
of it (but not in time for 6.5.1, I fear).

			regards, tom lane

Fri, 16 Jul 1999 13:25:12 -0400
Tom Lane <tgl@sss.pgh.pa.us>
Re: [HACKERS] [leon@udmnet.ru: [GENERAL] Weird behavior of 'default
	user']