Re: ecpg problem : pre-processor translated long constant to char

Поиск
Список
Период
Сортировка
От Michael Meskes
Тема Re: ecpg problem : pre-processor translated long constant to char
Дата
Msg-id 20020704142101.GA32633@feivel.credativ.de
обсуждение исходный текст
Ответ на ecpg problem : pre-processor translated long constant to char  (Raymond Fung <raymondf@acm.org>)
Список pgsql-hackers
On Thu, Jul 04, 2002 at 10:00:01AM +0800, Raymond Fung wrote:
> Dear all,
> ...
> It has translated the 4 bytes constant (0x87654321) into a one byte
> char constant (within the single quotes) during pre-processing. Seems
> this happens only when the high bit of the constant is set (i.e. it
> won't add the quotes if the constant is 0x12345678).

Yes, this is a bug. But look here:

mm=# create table test (i int8);
CREATE
mm=# insert into test values (x'80000000');
ERROR:  Bad hexadecimal integer input '80000000'
mm=# insert into test values (1234567890123);
INSERT 22762 1

The reason is that both the backend parser and the ecpg parser use
strtol to parse the hex constant. And strtol does not like anything >
0x80000000.

> Also, I noticed that the line number reported during the preprocessing
> error output is incorrect : it is '1' less than the actual line number
> in the source file. As shown, I am using version 2.8.0 of ecpg. Is my
> version being too old to be buggy ? Any suggestion to bypass the
> translation problem ?

I heard about the off-by-one problem sometimes, but I've yet to find the
time to look for the reason. A collegue is bugging me all the time. :-)

Michael
--
Michael Meskes
Michael@Fam-Meskes.De
Go SF 49ers! Go Rhein Fire!
Use Debian GNU/Linux! Use PostgreSQL!



В списке pgsql-hackers по дате отправления:

Предыдущее
От: Bruce Momjian
Дата:
Сообщение: Re: BETWEEN Node & DROP COLUMN
Следующее
От: Thomas Lockhart
Дата:
Сообщение: IS DISTINCT FROM and TREAT() committed