Re: Let's use libpq for everything

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

In response to

Browse pgsql-odbc by date

  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