Re: ODBC Rewrite
От | markw@mohawksoft.com |
---|---|
Тема | Re: ODBC Rewrite |
Дата | |
Msg-id | 16646.24.91.171.78.1102434990.squirrel@mail.mohawksoft.com обсуждение исходный текст |
Ответ на | Re: ODBC Rewrite (Stephen Frost <sfrost@snowman.net>) |
Список | pgsql-odbc |
> * markw@mohawksoft.com (markw@mohawksoft.com) wrote: >> > * markw@mohawksoft.com (markw@mohawksoft.com) wrote: >> >> > * markw@mohawksoft.com (markw@mohawksoft.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 >
В списке pgsql-odbc по дате отправления: