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 17:07:56 |
Message-ID: | 26184.1526663276@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:
>> From: Tom Lane [mailto:tgl(at)sss(dot)pgh(dot)pa(dot)us]
>> BTW, is it possible to set up an ecpg test case to verify that this stuff
>> works?
>> It'd have to handle platforms without long long though, so I'm not
>> sure how to deal with that.
> Yes. I was expecting that at least bigint will works fine with sqlda in linux
> system but it seem did not?
After some thought I decided that the right fix is to add coverage for
both ECPGt_long and ECPGt_long_long. Any given platform will test only
one of those two code paths, but that's probably fine, because that is
the only one it would use anyway.
Pushed it that way; the buildfarm will soon tell us if this was a
stupid idea ...
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2018-05-18 17:30:46 | Re: BUG #15080: ecpg on windows doesn't define HAVE_LONG_LONG_INT |
Previous Message | Tom Lane | 2018-05-18 15:07:52 | Re: BUG #15080: ecpg on windows doesn't define HAVE_LONG_LONG_INT |