From: | Thomas Lockhart <lockhart(at)fourpalms(dot)org> |
---|---|
To: | PostgreSQL Hackers List <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: CHAR constants |
Date: | 2002-07-13 14:32:50 |
Message-ID: | 3D303A12.FDEFD3B2@fourpalms.org |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
> > 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
From | Date | Subject | |
---|---|---|---|
Next Message | Bruce Momjian | 2002-07-13 14:33:02 | Re: 7.3 - current expectations for a release date |
Previous Message | Bruce Momjian | 2002-07-13 14:29:28 | Re: Unique and Primary Key Constraints |