Re: ODBC Rewrite

> * markw(at)mohawksoft(dot)com (markw(at)mohawksoft(dot)com) wrote:
>> > * markw(at)mohawksoft(dot)com (markw(at)mohawksoft(dot)com) wrote:
>> >> > * markw(at)mohawksoft(dot)com (markw(at)mohawksoft(dot)com) wrote:
>> >> >> Looking at both ODBC and libpq and I think that the difference is
>> >> that
>> >> >> libpq aims to make PostgreSQL interfacing easy, while ODBC strives
>> to
>> >> be
>> >> >> a
>> >> >> comprehensive SQL interface. 99% of what will be done with the
>> ODBC
>> >> >> interface will be simple SQLAllocStmt, SQLPrepare, and SQLExecute.
>> >> >
>> >> > Saying what 99% of what the ODBC driver does isn't terribly useful-
>> >> > What's that 1% that libpq can't do? Having looked at the code, can
>> >> you
>> >> > give us an idea on that?
>> >>
>> >> Off the top of my head, binding data to the SQL statement, reusing
>> >> statements, stuff like that.
>> >
>> > Isn't this handled by PQexecParams and PQexecPrepared?
>>
>> I had forgotten about those, but I was thinking more along the lines of
>> SQLBindCol.
>
> Ah, yes, that's not cleanly handled by the current libpq API, and is
> actually something I'd like to see added. Basically, a method to allow
> a query to go directly to a user-supplied memory area instead of the
> result being stored in memory by libpq. Perhaps this would lend some
> more weight to getting that added.
>
>> >> The ODBC API isn't designed to talk to any one database, so there are
>> no
>> >> short cuts. Unfortunately, applications based on ODBC assume there
>> are
>> >> no
>> >> short cuts, and rely on that behavior.
>> >
>> > That's not particularly relevant- the question is if the existing
>> libpq
>> > API is sufficient for the ODBC driver or not.
>>
>> You should take a look at:
>> http://msdn.microsoft.com/library/default.asp?url=/library/en-us/odbc/htm/odbcodbc_api_reference.asp
>>
>> There are a lot of things that would have to be synthisized using libpq,
>> but could be handled better using some of the primitives.
>
> I'm not sure that I agree... I'd rather see libpq flushed out a bit
> than have a large ODBC driver which requires alot of updating whenever
> libpq internals change.

That's what we have now. In my original email, I suggested that we either
create a low-level driver on which ODBC and libpq would be written, or
re-work libpq a bit and expose some primitives.

I'm also not sure that it's quite as bad as you
> seem to think.. Looking at the API from that link it really doesn't
> look all that large and many of the things seem to have correlation to
> existing libpq functions.
>
>> There were some things that Dave mentioned, but they escape me at the
>> moment.
>
> It seems to me like it'd be better to add the capabilities necessary to
> libpq so that others (such as myself) could benefit from them rather
> than write those capabilities solely into the ODBC driver.
>
> Thanks for your interest, by the way. I think there's a very good
> opportunity here to have a slim, fast and easily maintained ODBC driver
> and an improved libpq API.
>
> Stephen
>