Re: [HACKERS] libpq and prepared statements progress for 8.0

[Shachar Shemesh]

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/
---------------------------(end of broadcast)---------------------------
TIP 7: don't forget to increase your free space map settings