Re: Let's use libpq for everything

On 11/04/2014 01:22 AM, Heikki Linnakangas wrote:
> Hi everyone,
>
> In the long-term, I believe psqlodbc would be better off relying on
> libpq for all operations, and not touching the socket directly.

About +1000 from me after the recent fun I had debugging SSPI issues,
where I found it was sending version 1 protocol packets on the wire...

> I went ahead and replaced all the backend-interactions with libpq calls.
> I've pushed that to a development branch at:
> git@github.com:hlinnaka/psqlodbc.git, branch "libpq-integration4". It's
> not 100% complete - a few regression tests are failing - but it mostly
> works. Not surprisingly, this makes a lot of code unnecessary:
>
>  46 files changed, 1357 insertions(+), 7545 deletions(-)

That's what I like to see.

> 2. Using libpq functions requires more round-trips for some operations,
> because when speaking the protocol directly, you can "pipeline" some
> operations, and libpq doesn't expose functions to do that.

That's something that needs addressing in libpq, IMO.

It's been discussed on -hackers (I think) recently. I initially thought
we needed an API like JDBC's batch API, but was convinced that we really
should have something more generic than that.

The current async API:

http://www.postgresql.org/docs/8.1/static/libpq-async.html

doesn't permit pipelining, so we'd want to enhance it to allow that, by
lifting the restriction that:

"PQsendQuery may not be called again (on the same connection) until
PQgetResult has returned a null pointer, indicating that the command is
done."

and the same for the other variants.

So PGresult would have to carry more info and the global state less,
allowing libpq to keep track of the ordering of queries and wait until a
given result is ready.

It probably isn't that hard to do.

> 3. I'm not sure if I got all the less common "modes" like
> "DisallowPremature=1/0" and "Parse=1/0" to work the same they did
> before. I think we need to have a discussion on which modes we still
> need to support, and which are just legacy that we could remove.

I'd like to see a lot of that complexity and variation simply removed.

People who want the old stuff can use the old driver.

> Does anyone object to this as a goal?

I think it's absolutely great.

I don't use ODBC or have current support customers who use it, so I'm
going to be hard pressed to find time allocation for testing and helping
with this, but I'll see if I can dig some up. Or perhaps time to work on
pipeline support for libpq.

--
 Craig Ringer                   http://www.2ndQuadrant.com/
 PostgreSQL Development, 24x7 Support, Training & Services