| From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
|---|---|
| To: | Huong Dangminh <huo-dangminh(at)ys(dot)jp(dot)nec(dot)com> |
| Cc: | Jonathan Allen <jallen(at)americansavingslife(dot)com>, Michael Meskes <meskes(at)postgresql(dot)org>, Andrew Gierth <andrew(at)tao11(dot)riddles(dot)org(dot)uk>, "pgsql-bugs(at)lists(dot)postgresql(dot)org" <pgsql-bugs(at)lists(dot)postgresql(dot)org>, "Akio Iwaasa" <aki-iwaasa(at)vt(dot)jp(dot)nec(dot)com> |
| Subject: | Re: BUG #15080: ecpg on windows doesn't define HAVE_LONG_LONG_INT |
| Date: | 2018-05-18 15:07:52 |
| Message-ID: | 30158.1526656072@sss.pgh.pa.us |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-bugs |
Huong Dangminh <huo-dangminh(at)ys(dot)jp(dot)nec(dot)com> writes:
>> Attached test patch works fine in Windows, but in Linux system the
>> sqlda->sqlvar[i].sqltype return ECPGt_long but not ECPGt_long_long (as
>> expected) when reference to bigint column.
>> Is this another problem in linux? Or am I wrong something?
That would depend on what platform you're running on: if it's 64-bit
then "long int" is probably 64 bits wide, making that a perfectly valid
answer.
AIUI, the idea in ecpg is to support "long long int" program variables
if the compiler has such a type, without any particular assumptions about
how wide that type is. But whether the SQL type int8 maps to long or
long long is going to be platform-specific, which evidently is another
hurdle to testing anything here :-(
regards, tom lane
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Tom Lane | 2018-05-18 17:07:56 | Re: BUG #15080: ecpg on windows doesn't define HAVE_LONG_LONG_INT |
| Previous Message | Dave Cramer | 2018-05-18 14:23:46 | Re: JDBC problem in 10.3 / 10.4 |