Re: libpq and prepared statements progress for 8.0

Harald Fuchs wrote:

>>The first problem with this approach is that it requires libpq to be all
>>things to all people. We've already had some discussion in this thread
>>about the tension between supporting application programs written in C,
>>which want one set of features, and drivers, which need some other ones.
>>After awhile you end up with a bloated, probably buggy library. We're
>>already some way down that path, and I don't care to go much further.
>>
>>
>
>I don't think that's what David meant, although he said so :-)
>
>What we should have is a C API especially for use by driver authors;
>probably this API is so far away from the rest of libpq that it should
>not be part of it.
>
OLE DB is based on libpq. While the proposed function would be very nice
to have (and, in fact, needed for some obscure semantics of the OLE DB
protocol that no one really uses), at the moment there are NO major
features missing from OLE DB that cannot be provided using the existing
code. This may be a result of libpq going some way down bloat av., as
Tom said, but personally I don't see the need for a separate API.

I have not delved too deeply into the ODBC sources, so I can't attest to
the feasibility of using libpq there.

>This API could make life easier for driver authours, resulting in more
>and better drivers for more languages.
>
I'm really interested in what this would provide. It could be that I'm
missing something painfully obvious here, but why are driver developers
in such a different situation than end users?

Don't get me wrong. Having an API to fill data from the server directly
into user's buffers would be nice. However, as OLE DB transfers data in
binary, as most data types require conversion, and as some of the OLD DB
"accessors" are really weird, I doubt a sane API can be written that I'd
use anyways.

Likewise, having an API that does gradual delivery of data would be
nice. However, things really can be achieved using the asynchronous
libpq mechanism, and proper cursors can achieve most of the rest.

In short, I may be missing something painfully simple here, but I don't
see the real need for a driver oriented backend communication library.

Shachar

--
Shachar Shemesh
Lingnu Open Source Consulting ltd.
http://www.lingnu.com/