Re: [HACKERS] Parser bug (?)

"Oliver Elphick" <olly@lfix.co.uk> writes:
> This looks like a parser bug in 6.4.  I found it while trying to run
> pg_upgrade:
> bray=> create table junk ("singleton" "char");
> CREATE
> bray=> drop table junk;
> DROP
> bray=> create table junk ("singleton" "char" default 'M');
> ERROR:  DEFAULT: const type mismatched
> bray=> create table junk ("singleton" char default 'M');
> CREATE

Oh my, that's interesting ... and it looks like it is closely related
to my gripe a few days ago that type char is actually implemented as
char(1), or more accurately type bpchar(1).

I didCREATE TABLE t1 (c1 char, c2 "char");

and then looked at the info for the relation in pg_attribute:

attname|atttypid|attlen|attnum|attnelems|atttypmod|attbyval|attalign
-------+--------+------+------+---------+---------+--------+--------
c1     |    1042|    -1|     1|        0|        5|f       |i       
c2     |      18|     1|     2|        0|       -1|t       |c       

pg_type contains

oid|typname|typowner|typlen|typprtlen|typbyval|typtype|typisdefined|typdelim|typrelid|typelem|typinput|typoutput|typreceive|typsend
|typalign|typdefault
 

----+-------+--------+------+---------+--------+-------+------------+--------+--------+-------+--------+---------+----------+---------+--------+----------
18|char  |     256|     1|        1|t       |b      |t           |,       |       0|      0|charin  |charout  |charin
|charout  |c       |
 
1042|bpchar |     256|    -1|       -1|f       |b      |t           |,       |       0|
18|bpcharin|bpcharout|bpcharin |bpcharout|i       |
 


So it appears that *something* (probably the parser) is converting the
unquoted type name char to a bpchar (blank-padded char array),
but if it's quoted then you actually get the primitive char type.

Seems to me that that's a bug: if you ask for char, and not char(1), you
should get char.  At least I'd like it to be a bug, because I want to be
able to use the unvarnished char type, and I don't want to depend on
some weird quoting behavior to get at it.

The second bug exhibited by Oliver's example is that a literal 'M'
is not recognized as compatible with the primitive char type.
That won't do either.

I tried coercing the 'M' to a char explicitly, just to see what would
happen, and got a coredump:

create table junk ("singleton" "char" default 'M'::char);
pqReadData() -- backend closed the channel unexpectedly.       This probably means the backend terminated abnormally
beforeor while processing the request.
 
We have lost the connection to the backend, so further processing is impossible.  Terminating.

Backtrace is

#0  0x800c4234 in _strlen ()
#1  0xca87c in FlattenStringList (list=0x4008dd58) at gram.y:5047
#2  0xc6380 in yyparse () at gram.y:845
#3  0xcac8c in parser (   str=0x7b034218 "create table junk (\"singleton\" \"char\" default 'M'::char);", typev=0x0,
nargs=0)at parser.c:53
 
#4  0xf1c0c in pg_parse_and_plan (   query_string=0x7b034218 "create table junk (\"singleton\" \"char\" default
'M'::char);",typev=0x7b038550, nargs=0, queryListP=0x7b036358, dest=Remote,   aclOverride=0) at postgres.c:420
 

Ooops.  Looks like FlattenStringList is getting handed a node type it
was not expecting.  The elements of the list it is handed are:

$6 = {type = T_String, val = {str = 0x41b6c "CAST", ival = 269164,   dval = 5.7116487507937656e-309}}
$8 = {type = T_String, val = {str = 0x4008d910 "'M'", ival = 1074321680,   dval = 3.105987548828125}}
$10 = {type = T_String, val = {str = 0x41b74 "AS", ival = 269172,   dval = 5.7118185104570428e-309}}
$12 = {type = T_TypeName, val = {str = 0x5 <Address 0x5 out of bounds>,   ival = 5, dval = 1.0609978954826362e-313}}

So that's another bug, though possibly unrelated.
        regards, tom lane