CHAR constants

Started by Thomas Lockhartover 23 years ago3 messages
#1Thomas Lockhart
lockhart@fourpalms.org

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

#2Tom Lane
tgl@sss.pgh.pa.us
In reply to: Thomas Lockhart (#1)
Re: 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

#3Thomas Lockhart
lockhart@fourpalms.org
In reply to: Thomas Lockhart (#1)
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