We too don't want to do so. However until the testing of new libpq odbc
driver is completed, the user can have an option of using socket code or
libpq code.
Once the new libpq odbc driver is stable we can get rid of the socket
stuff.
Regards,
Siva Kumar.K
-----Original Message-----
From: Dave Page [mailto:dpage@vale-housing.co.uk]
Sent: Tuesday, June 07, 2005 3:01 PM
To: Sivakumar K; pgman@candle.pha.pa.us; fuerth@sqlpower.ca
Cc: jd@commandprompt.com; pgsql-odbc@postgresql.org
Subject: RE: [ODBC] Frontend/Backend protocol 3.0
> -----Original Message-----
> From: pgsql-odbc-owner@postgresql.org
> [mailto:pgsql-odbc-owner@postgresql.org] On Behalf Of Sivakumar K
> Sent: 07 June 2005 09:44
> To: pgman@candle.pha.pa.us; fuerth@sqlpower.ca
> Cc: jd@commandprompt.com; pgsql-odbc@postgresql.org
> Subject: Re: [ODBC] Frontend/Backend protocol 3.0
>
> Hi all,
>
> In continuation to my previous mail, here is an overview on
> the approach
> that we have taken. We had a few design goals when we started on this
> exercise.
>
> 1. ODBC driver should still support socket mode.
> 2. Use if-defs minimally.
> 3. The code change should be minimal.
> 4. Use a compile time flag USE_LIBPQ to switch between libPQ
> and socket.
Why keep the socket stuff? The whole point is to get rid of it and the
associated complexity and rely on libpq.
Regards, Dave.