From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Heikki Linnakangas <hlinnakangas(at)vmware(dot)com> |
Cc: | Michael Paquier <michael(dot)paquier(at)gmail(dot)com>, Craig Ringer <craig(at)2ndquadrant(dot)com>, "pgsql-odbc(at)postgresql(dot)org" <pgsql-odbc(at)postgresql(dot)org> |
Subject: | Re: Let's use libpq for everything |
Date: | 2014-12-09 17:42:49 |
Message-ID: | 5768.1418146969@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-odbc |
Heikki Linnakangas <hlinnakangas(at)vmware(dot)com> writes:
> On 11/28/2014 09:09 AM, Michael Paquier wrote:
>> 5) In lobj.c, there are mentions of using lo_lseek64 and lo_tell64. I
>> am not sure that this is a good thing at this state: those functions
>> have been added in 9.3 and we still have many users with PG <= 9.2. It
>> may be better to add a note about updating to those functions when the
>> minimum support requirement is 9.3.
> Well, it's just a comment.
Not qualified to review this patch in total, but as far as that goes:
libpq provides an inexpensive way to check the server version, so you
could easily have a code path using the newer functions when available.
The big problem is that odbc_lo_lseek/odbc_lo_tell are declared as
taking/returning int4 not int8; unless you can widen those values without
breaking the library ABI, there is zero point in using the newer
server-side functions.
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Michael Paquier | 2014-12-10 05:32:05 | Regression failures for test col_attributes.sql introduced recently |
Previous Message | Heikki Linnakangas | 2014-12-09 16:20:46 | Re: Let's use libpq for everything |