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. 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