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 по дате отправления: