Skip site navigation (1) Skip section navigation (2)

Re: ODBC Rewrite

From: markw(at)mohawksoft(dot)com
To: "Stephen Frost" <sfrost(at)snowman(dot)net>
Cc: pgsql-odbc(at)postgresql(dot)org
Subject: Re: ODBC Rewrite
Date: 2004-12-07 15:56:30
Message-ID: (view raw, whole thread or download thread mbox)
Lists: pgsql-odbc
> * 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
>> >> >> 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:
>> 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

In response to

pgsql-odbc by date

Next:From: Eric EDate: 2004-12-07 18:41:14
Subject: Re: ODBC Rewrite
Previous:From: Tom LaneDate: 2004-12-07 15:32:25
Subject: Re: ODBC Rewrite

Privacy Policy | About PostgreSQL
Copyright © 1996-2017 The PostgreSQL Global Development Group