So, what should the behavior be of a constant declared as

CHAR 'hi'

? Right now it fails, since SQL9x asks that the char type defaults to a
length of one and our parser does not distinguish between usage as a
constant declaration and as a column definition (where you would want
the "char(1)" to be filled in). But istm that for a constant string, the
length should be whatever the string is, or unspecified.

Comments?

                     - Thomas

Fri, 12 Jul 2002 08:42:44 -0700
Thomas Lockhart <lockhart@fourpalms.org>
CHAR constants
Thomas Lockhart <lockhart@fourpalms.org> writes:
> So, what should the behavior be of a constant declared as
> CHAR 'hi'

> ? Right now it fails, since SQL9x asks that the char type defaults to a
> length of one and our parser does not distinguish between usage as a
> constant declaration and as a column definition (where you would want
> the "char(1)" to be filled in). But istm that for a constant string, the
> length should be whatever the string is, or unspecified.

Seems we should convert that to char(2).  Not sure how difficult it is
to do though...

			regards, tom lane

Fri, 12 Jul 2002 13:09:09 -0400
Tom Lane <tgl@sss.pgh.pa.us>
Re: CHAR constants 
> > So, what should the behavior be of a constant declared as
> > CHAR 'hi'
> > ? Right now it fails, since SQL9x asks that the char type defaults to a
> > length of one and our parser does not distinguish between usage as a
> > constant declaration and as a column definition (where you would want
> > the "char(1)" to be filled in). But istm that for a constant string, the
> > length should be whatever the string is, or unspecified.

OK, I've got patches (not yet applied; any comments before they go
in??)...

> Seems we should convert that to char(2).  Not sure how difficult it is
> to do though...

afaict there is no need to internally set a specific length; it is
sufficient to set typmod to -1 *in this case only*. So I've got patches
which separate uses of character string declarations in constants vs
others (e.g. column declarations).

So, before patches this fails:

thomas=# select char 'hi';
ERROR:  value too long for type character(1)

and after patches:

thomas=# select char 'hi';
 bpchar 
--------
 hi
(1 row)

thomas=# select char(1) 'hi';
ERROR:  value too long for type character(1)


btw, I first tried solving this with in-line actions just setting a flag
to indicate that this was going to be a production for a constant. And
probably set a record for shift/reduce conflicts:

bison -y -d  -v gram.y
conflicts:  20591 shift/reduce, 10 reduce/reduce

Woohoo!! :)

                     - Thomas

Sat, 13 Jul 2002 07:32:50 -0700
Thomas Lockhart <lockhart@fourpalms.org>
Re: CHAR constants