Thread: Frontend/Backend protocol 3.0
Hello people, I've taken a few days to hack in support for the frontend/backend protocol v3.0 (which first appeared in PostgreSQL 7.4). My main motivator was to get at the SQLSTATE codes which backends >= 7.4 return with every error message. What's done now: -read the new message length field from all server responses -Parse new-style error/notice blocks -return correct SQLSTATE from backend to ODBC callers (connection and result level) -added #ifdef so the driver compiles against newer iODBC headers What I intend to finish this week: -upgrade the function call API to new protocol What needs doing that I can't/won't finish soon: -upgrade Windows configuration GUI to add new "7.4" protocol option -take advantage of the new transaction status byte in 'Z' messages (my patch just ignores them) -rework prepared statement stuff to use the new protocol features (I haven't looked at this stuff at all, but the old code works on the new protocol--it could be faster, that's all) If there is any interest in this patch, I will post it to the list, or email it to individuals. Regards, -Jonathan Fuerth
That is great. I've been using psqlodbc and missed a proper error code / sqlstate Andrei Jonathan Fuerth wrote: > Hello people, > > I've taken a few days to hack in support for the frontend/backend > protocol v3.0 (which first appeared in PostgreSQL 7.4). My main > motivator was to get at the SQLSTATE codes which backends >= 7.4 > return with every error message. > > What's done now: > -read the new message length field from all server responses > -Parse new-style error/notice blocks > -return correct SQLSTATE from backend to ODBC callers (connection and > result level) > -added #ifdef so the driver compiles against newer iODBC headers > > What I intend to finish this week: > -upgrade the function call API to new protocol > > What needs doing that I can't/won't finish soon: > -upgrade Windows configuration GUI to add new "7.4" protocol option > -take advantage of the new transaction status byte in 'Z' messages > (my patch just ignores them) > -rework prepared statement stuff to use the new protocol features (I > haven't looked at this stuff at all, but the old code works on the new > protocol--it could be faster, that's all) > > If there is any interest in this patch, I will post it to the list, or > email it to individuals. > > Regards, > > -Jonathan Fuerth > > > ---------------------------(end of broadcast)--------------------------- > TIP 9: the planner will ignore your desire to choose an index scan if > your > joining column's datatypes do not match > > -- No virus found in this outgoing message. Checked by AVG Anti-Virus. Version: 7.0.322 / Virus Database: 267.5.1 - Release Date: 6/2/2005
On Jun 3, 2005, at 3:44 AM, Andrei Gaspar wrote: > That is great. > I've been using psqlodbc and missed a proper error code / sqlstate > Yeah. We absolutely needed it for a project we're implementing on postgres, so I had to do it. :) Someone else asked me in an off-list message if this patch adds support for the new 'P' and 'B' frontend messages (for more efficient prepared statement handling--the JDBC driver already supports this). It does not.. I mentioned that under the "what I can't/won't do soon" section. I think it's a good idea, and someone should do it. I might do it some day, but I have to get back to more pressing things next week. -Jonathan Fuerth
Are you aware someone is rewriting ODBC to use libpq for protocol communications? --------------------------------------------------------------------------- Jonathan Fuerth wrote: > Hello people, > > I've taken a few days to hack in support for the frontend/backend > protocol v3.0 (which first appeared in PostgreSQL 7.4). My main > motivator was to get at the SQLSTATE codes which backends >= 7.4 return > with every error message. > > What's done now: > -read the new message length field from all server responses > -Parse new-style error/notice blocks > -return correct SQLSTATE from backend to ODBC callers (connection and > result level) > -added #ifdef so the driver compiles against newer iODBC headers > > What I intend to finish this week: > -upgrade the function call API to new protocol > > What needs doing that I can't/won't finish soon: > -upgrade Windows configuration GUI to add new "7.4" protocol option > -take advantage of the new transaction status byte in 'Z' messages (my > patch just ignores them) > -rework prepared statement stuff to use the new protocol features (I > haven't looked at this stuff at all, but the old code works on the new > protocol--it could be faster, that's all) > > If there is any interest in this patch, I will post it to the list, or > email it to individuals. > > Regards, > > -Jonathan Fuerth > > > ---------------------------(end of broadcast)--------------------------- > TIP 9: the planner will ignore your desire to choose an index scan if your > joining column's datatypes do not match > -- Bruce Momjian | http://candle.pha.pa.us pgman@candle.pha.pa.us | (610) 359-1001 + If your life is a hard drive, | 13 Roberts Road + Christ can be your backup. | Newtown Square, Pennsylvania 19073
On Jun 3, 2005, at 5:20 PM, Bruce Momjian wrote: > > Are you aware someone is rewriting ODBC to use libpq for protocol > communications? > No, but it sounds like an excellent idea. In the mean time, I can enjoy sqlstate error messages with the patch on the cuerrent driver. You might consider getting someone to put mention of that project on the psqlodbc website. Thanks for the heads-up! -Jonathan
On Jun 3, 2005, at 5:20 PM, Bruce Momjian wrote: > > Are you aware someone is rewriting ODBC to use libpq for protocol > communications? I found the announcement from Command Prompt about their new ODBC driver for PostgreSQL. If anyone else didn't know about this, here's the thread: http://archives.postgresql.org/pgsql-odbc/2005-04/msg00084.php It looks like an ambitious project, but I'm sure they have the dedication, talent, and resources to see it through to completion. I eagerly await their initial public release along with everyone else here who has the misfortune of needing to use an ODBC interface. :) In the mean time, my patch for the existing driver remains on offer to anyone who wants access to the SQLSTATE error messages from the backend. Better yet, maybe someone with the necessary permission can post the patch to the gborg website or just apply it to the main code in CVS. I think the only change that should be made before applying my patch is to add "7.4" as a protocol choice in the Windows configuration UI. It should be trivial for someone who understands that UI code (I don't). The patch does not break compatibility with the older protocols, so you can continue to use the patched driver with pre-7.4 backends. You will get the same synthetic SQLSTATE codes as before if you connect using the older protocols. Regards, -Jonathan Fuerth
The work is actually being done by another company, Pervasive. The Command Prompt version is to be GPL and is quite different. --------------------------------------------------------------------------- Jonathan Fuerth wrote: > On Jun 3, 2005, at 5:20 PM, Bruce Momjian wrote: > > > > Are you aware someone is rewriting ODBC to use libpq for protocol > > communications? > > I found the announcement from Command Prompt about their new ODBC > driver for PostgreSQL. If anyone else didn't know about this, here's > the thread: > > http://archives.postgresql.org/pgsql-odbc/2005-04/msg00084.php > > It looks like an ambitious project, but I'm sure they have the > dedication, talent, and resources to see it through to completion. I > eagerly await their initial public release along with everyone else > here who has the misfortune of needing to use an ODBC interface. :) > > In the mean time, my patch for the existing driver remains on offer to > anyone who wants access to the SQLSTATE error messages from the > backend. Better yet, maybe someone with the necessary permission can > post the patch to the gborg website or just apply it to the main code > in CVS. I think the only change that should be made before applying my > patch is to add "7.4" as a protocol choice in the Windows configuration > UI. It should be trivial for someone who understands that UI code (I > don't). > > The patch does not break compatibility with the older protocols, so you > can continue to use the patched driver with pre-7.4 backends. You will > get the same synthetic SQLSTATE codes as before if you connect using > the older protocols. > > Regards, > > -Jonathan Fuerth > > > ---------------------------(end of broadcast)--------------------------- > TIP 7: don't forget to increase your free space map settings > -- Bruce Momjian | http://candle.pha.pa.us pgman@candle.pha.pa.us | (610) 359-1001 + If your life is a hard drive, | 13 Roberts Road + Christ can be your backup. | Newtown Square, Pennsylvania 19073
--- Bruce Momjian <pgman@candle.pha.pa.us> wrote: > > The work is actually being done by another company, > Pervasive. The This is news, at least to me. Is this a reworking of the community driver, or a new product? > Command Prompt version is to be GPL and is quite > different. > > --------------------------------------------------------------------------- > > Jonathan Fuerth wrote: > > On Jun 3, 2005, at 5:20 PM, Bruce Momjian wrote: > > > > > > Are you aware someone is rewriting ODBC to use > libpq for protocol > > > communications? > > > > I found the announcement from Command Prompt about > their new ODBC > > driver for PostgreSQL. If anyone else didn't know > about this, here's > > the thread: > > > > > http://archives.postgresql.org/pgsql-odbc/2005-04/msg00084.php > > > > It looks like an ambitious project, but I'm sure > they have the > > dedication, talent, and resources to see it > through to completion. I > > eagerly await their initial public release along > with everyone else > > here who has the misfortune of needing to use an > ODBC interface. :) > > > > In the mean time, my patch for the existing driver > remains on offer to > > anyone who wants access to the SQLSTATE error > messages from the > > backend. Better yet, maybe someone with the > necessary permission can > > post the patch to the gborg website or just apply > it to the main code > > in CVS. I think the only change that should be > made before applying my > > patch is to add "7.4" as a protocol choice in the > Windows configuration > > UI. It should be trivial for someone who > understands that UI code (I > > don't). > > > > The patch does not break compatibility with the > older protocols, so you > > can continue to use the patched driver with > pre-7.4 backends. You will > > get the same synthetic SQLSTATE codes as before if > you connect using > > the older protocols. > > > > Regards, > > > > -Jonathan Fuerth > > > > > > ---------------------------(end of > broadcast)--------------------------- > > TIP 7: don't forget to increase your free space > map settings > > > > -- > Bruce Momjian | > http://candle.pha.pa.us > pgman@candle.pha.pa.us | (610) > 359-1001 > + If your life is a hard drive, | 13 Roberts > Road > + Christ can be your backup. | Newtown > Square, Pennsylvania 19073 > > ---------------------------(end of > broadcast)--------------------------- > TIP 7: don't forget to increase your free space map > settings > __________________________________ Discover Yahoo! Have fun online with music videos, cool games, IM and more. Check it out! http://discover.yahoo.com/online.html
Jeff Eckermann wrote: > --- Bruce Momjian <pgman@candle.pha.pa.us> wrote: > > > > > The work is actually being done by another company, > > Pervasive. The > > This is news, at least to me. Is this a reworking of > the community driver, or a new product? Reworking the community driver. --------------------------------------------------------------------------- > > > Command Prompt version is to be GPL and is quite > > different. > > > > > --------------------------------------------------------------------------- > > > > Jonathan Fuerth wrote: > > > On Jun 3, 2005, at 5:20 PM, Bruce Momjian wrote: > > > > > > > > Are you aware someone is rewriting ODBC to use > > libpq for protocol > > > > communications? > > > > > > I found the announcement from Command Prompt about > > their new ODBC > > > driver for PostgreSQL. If anyone else didn't know > > about this, here's > > > the thread: > > > > > > > > > http://archives.postgresql.org/pgsql-odbc/2005-04/msg00084.php > > > > > > It looks like an ambitious project, but I'm sure > > they have the > > > dedication, talent, and resources to see it > > through to completion. I > > > eagerly await their initial public release along > > with everyone else > > > here who has the misfortune of needing to use an > > ODBC interface. :) > > > > > > In the mean time, my patch for the existing driver > > remains on offer to > > > anyone who wants access to the SQLSTATE error > > messages from the > > > backend. Better yet, maybe someone with the > > necessary permission can > > > post the patch to the gborg website or just apply > > it to the main code > > > in CVS. I think the only change that should be > > made before applying my > > > patch is to add "7.4" as a protocol choice in the > > Windows configuration > > > UI. It should be trivial for someone who > > understands that UI code (I > > > don't). > > > > > > The patch does not break compatibility with the > > older protocols, so you > > > can continue to use the patched driver with > > pre-7.4 backends. You will > > > get the same synthetic SQLSTATE codes as before if > > you connect using > > > the older protocols. > > > > > > Regards, > > > > > > -Jonathan Fuerth > > > > > > > > > ---------------------------(end of > > broadcast)--------------------------- > > > TIP 7: don't forget to increase your free space > > map settings > > > > > > > -- > > Bruce Momjian | > > http://candle.pha.pa.us > > pgman@candle.pha.pa.us | (610) > > 359-1001 > > + If your life is a hard drive, | 13 Roberts > > Road > > + Christ can be your backup. | Newtown > > Square, Pennsylvania 19073 > > > > ---------------------------(end of > > broadcast)--------------------------- > > TIP 7: don't forget to increase your free space map > > settings > > > > > > > __________________________________ > Discover Yahoo! > Have fun online with music videos, cool games, IM and more. Check it out! > http://discover.yahoo.com/online.html > > ---------------------------(end of broadcast)--------------------------- > TIP 7: don't forget to increase your free space map settings > -- Bruce Momjian | http://candle.pha.pa.us pgman@candle.pha.pa.us | (610) 359-1001 + If your life is a hard drive, | 13 Roberts Road + Christ can be your backup. | Newtown Square, Pennsylvania 19073
On Jun 6, 2005, at 1:55 PM, Bruce Momjian wrote: > > The work is actually being done by another company, Pervasive. The > Command Prompt version is to be GPL and is quite different. > Ok, cool. Where can I find more information about that? I searched this list, googled for "pervasive odbc postgres," and poked around on pervasive.com, but came up dry. I did read the licensing debate in that Command Prompt thread, but it seemed that the consensus was that an ODBC driver links with the driver manager--not the application code--and so the GPL doesn't leak out and infect ODBC client applications that happen to work with a GPL'ed ODBC driver. I guess there would have to be a public statement from Command Prompt, or legal precedent, to make this point of view a little more trustworthy and official. If this interpretation was correct, would it be legal to bundle a GPL'ed ODBC driver with a closed-source application? It certainly did seem to be Command Prompt's intention from the outset to use the dual license model to require "fee-based commercial use," otherwise they could have chosen a less restrictive open source license. If there's anyone left with access to update the psqlodbc gborg site, maybe they could put up a list of links to the "alternative" PostgreSQL ODBC driver projects (and maybe mention the licensing model of each). I don't think I'm the only person who has been suffering from a lack of background knowledge in this regard. Cheers, -Jonathan Fuerth
Jonathan Fuerth wrote: > On Jun 6, 2005, at 1:55 PM, Bruce Momjian wrote: > > > > The work is actually being done by another company, Pervasive. The > > Command Prompt version is to be GPL and is quite different. > > > Ok, cool. Where can I find more information about that? I searched > this list, googled for "pervasive odbc postgres," and poked around on > pervasive.com, but came up dry. > > I did read the licensing debate in that Command Prompt thread, but it > seemed that the consensus was that an ODBC driver links with the driver > manager--not the application code--and so the GPL doesn't leak out and > infect ODBC client applications that happen to work with a GPL'ed ODBC > driver. I guess there would have to be a public statement from Command > Prompt, or legal precedent, to make this point of view a little more > trustworthy and official. If this interpretation was correct, would it > be legal to bundle a GPL'ed ODBC driver with a closed-source > application? > > It certainly did seem to be Command Prompt's intention from the outset > to use the dual license model to require "fee-based commercial use," > otherwise they could have chosen a less restrictive open source > license. > > If there's anyone left with access to update the psqlodbc gborg site, > maybe they could put up a list of links to the "alternative" PostgreSQL > ODBC driver projects (and maybe mention the licensing model of each). > I don't think I'm the only person who has been suffering from a lack of > background knowledge in this regard. OK, who is working on improving ODBC at this point? Please give us a status report. -- Bruce Momjian | http://candle.pha.pa.us pgman@candle.pha.pa.us | (610) 359-1001 + If your life is a hard drive, | 13 Roberts Road + Christ can be your backup. | Newtown Square, Pennsylvania 19073
>>If there's anyone left with access to update the psqlodbc gborg site, >>maybe they could put up a list of links to the "alternative" PostgreSQL >>ODBC driver projects (and maybe mention the licensing model of each). >>I don't think I'm the only person who has been suffering from a lack of >>background knowledge in this regard. > > > OK, who is working on improving ODBC at this point? Please give us a > status report. My understanding is that there are two ODBC Projects. 1. ODBCng which is the GPL Command Prompt venture 2. ODBC which is the original LGPL version and is being worked on by Pervasive. In the end it will truly be a which one works for you kind of thing. ODBCng for example will not use libpq. Sincerely, Joshua D. Drake -- Your PostgreSQL solutions company - Command Prompt, Inc. 1.800.492.2240 PostgreSQL Replication, Consulting, Custom Programming, 24x7 support Managed Services, Shared and Dedicated Hosting Co-Authors: plPHP, plPerlNG - http://www.commandprompt.com/
On Jun 6, 2005, at 5:39 PM, Joshua D. Drake wrote: >>> I don't think I'm the only person who has been suffering from a lack >>> of background knowledge in this regard. >> OK, who is working on improving ODBC at this point? Please give us a >> status report. > > My understanding is that there are two ODBC Projects. > > 1. ODBCng which is the GPL Command Prompt venture This seems clear enough--a from-scratch, GPL/commercial licensed ODBC driver which doesn't use libpq and only works with PostgreSQL backend >=8.0. Command Prompt will host this separately from the existing psqlodbc project. > 2. ODBC which is the original LGPL version and is being worked on by > Pervasive. I'm fuzzy on this one. Is pervasive just contributing incremental updates to the existing driver in the existing CVS repository, or will they post a lump-sum update to the driver one day, or will they fork the project and host their version on their own site? I can't find any evidence that they've publicly forked the project (or made any improvements to the odbc driver), but that doesn't mean they haven't been working on something in secret. Thanks for helping me discover these other projects. Now that we can get SQLSTATE from the backend, the driver works with our product (which is not open source). The next step will be to optimise SQL INSERT and UPDATE performance, and the most obvious place to start is with the new bind/execute part of the v3 backend protocol. I'm trying to decide if it's worth implementing on top of our current patched driver, or if I should just wait for Pervasive or Command Prompt to do it. -Jonathan Fuerth
Jonathan Fuerth wrote: > On Jun 6, 2005, at 5:39 PM, Joshua D. Drake wrote: > >>> I don't think I'm the only person who has been suffering from a lack > >>> of background knowledge in this regard. > >> OK, who is working on improving ODBC at this point? Please give us a > >> status report. > > > > My understanding is that there are two ODBC Projects. > > > > 1. ODBCng which is the GPL Command Prompt venture > > This seems clear enough--a from-scratch, GPL/commercial licensed ODBC > driver which doesn't use libpq and only works with PostgreSQL backend > >=8.0. Command Prompt will host this separately from the existing > psqlodbc project. > > > 2. ODBC which is the original LGPL version and is being worked on by > > Pervasive. > > I'm fuzzy on this one. Is pervasive just contributing incremental > updates to the existing driver in the existing CVS repository, or will > they post a lump-sum update to the driver one day, or will they fork > the project and host their version on their own site? > > I can't find any evidence that they've publicly forked the project (or > made any improvements to the odbc driver), but that doesn't mean they > haven't been working on something in secret. > > Thanks for helping me discover these other projects. Now that we can > get SQLSTATE from the backend, the driver works with our product (which > is not open source). > > The next step will be to optimise SQL INSERT and UPDATE performance, > and the most obvious place to start is with the new bind/execute part > of the v3 backend protocol. I'm trying to decide if it's worth > implementing on top of our current patched driver, or if I should just > wait for Pervasive or Command Prompt to do it. I am fuzzy on what Pervasive is doing and hope they will jump into this discussion. -- Bruce Momjian | http://candle.pha.pa.us pgman@candle.pha.pa.us | (610) 359-1001 + If your life is a hard drive, | 13 Roberts Road + Christ can be your backup. | Newtown Square, Pennsylvania 19073
Hi all, We, at Pervasive, are working in making the ODBC driver use the libPQ API while retaining the socket connection too (using a compile time flag). We are planning to provide a lump-sum update on this task since it does not make sense for incremental updates. We are also doing bug-fixing and closing open bugs (where we can) in the drivers which are provided as incremental updates. I will post an email on approach shortly. Regards, Siva Kumar.K -----Original Message----- From: pgsql-odbc-owner@postgresql.org [mailto:pgsql-odbc-owner@postgresql.org] On Behalf Of Bruce Momjian Sent: Tuesday, June 07, 2005 5:05 AM To: Jonathan Fuerth Cc: Joshua D. Drake; pgsql-odbc@postgresql.org Subject: Re: [ODBC] Frontend/Backend protocol 3.0 Jonathan Fuerth wrote: > On Jun 6, 2005, at 5:39 PM, Joshua D. Drake wrote: > >>> I don't think I'm the only person who has been suffering from a lack > >>> of background knowledge in this regard. > >> OK, who is working on improving ODBC at this point? Please give us a > >> status report. > > > > My understanding is that there are two ODBC Projects. > > > > 1. ODBCng which is the GPL Command Prompt venture > > This seems clear enough--a from-scratch, GPL/commercial licensed ODBC > driver which doesn't use libpq and only works with PostgreSQL backend > >=8.0. Command Prompt will host this separately from the existing > psqlodbc project. > > > 2. ODBC which is the original LGPL version and is being worked on by > > Pervasive. > > I'm fuzzy on this one. Is pervasive just contributing incremental > updates to the existing driver in the existing CVS repository, or will > they post a lump-sum update to the driver one day, or will they fork > the project and host their version on their own site? > > I can't find any evidence that they've publicly forked the project (or > made any improvements to the odbc driver), but that doesn't mean they > haven't been working on something in secret. > > Thanks for helping me discover these other projects. Now that we can > get SQLSTATE from the backend, the driver works with our product (which > is not open source). > > The next step will be to optimise SQL INSERT and UPDATE performance, > and the most obvious place to start is with the new bind/execute part > of the v3 backend protocol. I'm trying to decide if it's worth > implementing on top of our current patched driver, or if I should just > wait for Pervasive or Command Prompt to do it. I am fuzzy on what Pervasive is doing and hope they will jump into this discussion. -- Bruce Momjian | http://candle.pha.pa.us pgman@candle.pha.pa.us | (610) 359-1001 + If your life is a hard drive, | 13 Roberts Road + Christ can be your backup. | Newtown Square, Pennsylvania 19073 ---------------------------(end of broadcast)--------------------------- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq
Dear All,
I had downloaded the .net data provider for postgres named Npgsql.Will Npgsql driver support the PostgreSQL 8.0 features, such as returning a RefCursors from a stored function?I am unable to display the RefCursors values in the .net data grid.
Can you please give me some samples?
Thanks and regards
BSRAJ
__________________________________________________
Do You Yahoo!?
Tired of spam? Yahoo! Mail has the best spam protection around
http://mail.yahoo.com
Hi all, In continuation to my previous mail, here is an overview on the approach that we have taken. We had a few design goals when we started on this exercise. 1. ODBC driver should still support socket mode. 2. Use if-defs minimally. 3. The code change should be minimal. 4. Use a compile time flag USE_LIBPQ to switch between libPQ and socket. During connection, we are including the pgconn into the ConnectionClass instead of SocketClass. This part is already done. For the resultSet, we are mapping pgresult to QResultClass in CC_send_query. All the data returned will be added to manual_tuples in QResultClass and the manual_result will be set to true in StatementClass. We are hoping there should be no more changes since only QResultClass is used in other places. We hope to be done on this by end of this week and will submit a patch early next week. Regards, Siva Kumar.K -----Original Message----- From: Sivakumar K Sent: Tuesday, June 07, 2005 11:21 AM To: 'pgman@candle.pha.pa.us'; 'fuerth@sqlpower.ca' Cc: 'jd@commandprompt.com'; 'pgsql-odbc@postgresql.org' Subject: RE: [ODBC] Frontend/Backend protocol 3.0 Hi all, We, at Pervasive, are working in making the ODBC driver use the libPQ API while retaining the socket connection too (using a compile time flag). We are planning to provide a lump-sum update on this task since it does not make sense for incremental updates. We are also doing bug-fixing and closing open bugs (where we can) in the drivers which are provided as incremental updates. I will post an email on approach shortly. Regards, Siva Kumar.K -----Original Message----- From: pgsql-odbc-owner@postgresql.org [mailto:pgsql-odbc-owner@postgresql.org] On Behalf Of Bruce Momjian Sent: Tuesday, June 07, 2005 5:05 AM To: Jonathan Fuerth Cc: Joshua D. Drake; pgsql-odbc@postgresql.org Subject: Re: [ODBC] Frontend/Backend protocol 3.0 Jonathan Fuerth wrote: > On Jun 6, 2005, at 5:39 PM, Joshua D. Drake wrote: > >>> I don't think I'm the only person who has been suffering from a lack > >>> of background knowledge in this regard. > >> OK, who is working on improving ODBC at this point? Please give us a > >> status report. > > > > My understanding is that there are two ODBC Projects. > > > > 1. ODBCng which is the GPL Command Prompt venture > > This seems clear enough--a from-scratch, GPL/commercial licensed ODBC > driver which doesn't use libpq and only works with PostgreSQL backend > >=8.0. Command Prompt will host this separately from the existing > psqlodbc project. > > > 2. ODBC which is the original LGPL version and is being worked on by > > Pervasive. > > I'm fuzzy on this one. Is pervasive just contributing incremental > updates to the existing driver in the existing CVS repository, or will > they post a lump-sum update to the driver one day, or will they fork > the project and host their version on their own site? > > I can't find any evidence that they've publicly forked the project (or > made any improvements to the odbc driver), but that doesn't mean they > haven't been working on something in secret. > > Thanks for helping me discover these other projects. Now that we can > get SQLSTATE from the backend, the driver works with our product (which > is not open source). > > The next step will be to optimise SQL INSERT and UPDATE performance, > and the most obvious place to start is with the new bind/execute part > of the v3 backend protocol. I'm trying to decide if it's worth > implementing on top of our current patched driver, or if I should just > wait for Pervasive or Command Prompt to do it. I am fuzzy on what Pervasive is doing and hope they will jump into this discussion. -- Bruce Momjian | http://candle.pha.pa.us pgman@candle.pha.pa.us | (610) 359-1001 + If your life is a hard drive, | 13 Roberts Road + Christ can be your backup. | Newtown Square, Pennsylvania 19073 ---------------------------(end of broadcast)--------------------------- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq
> -----Original Message----- > From: pgsql-odbc-owner@postgresql.org > [mailto:pgsql-odbc-owner@postgresql.org] On Behalf Of Sivakumar K > Sent: 07 June 2005 09:44 > To: pgman@candle.pha.pa.us; fuerth@sqlpower.ca > Cc: jd@commandprompt.com; pgsql-odbc@postgresql.org > Subject: Re: [ODBC] Frontend/Backend protocol 3.0 > > Hi all, > > In continuation to my previous mail, here is an overview on > the approach > that we have taken. We had a few design goals when we started on this > exercise. > > 1. ODBC driver should still support socket mode. > 2. Use if-defs minimally. > 3. The code change should be minimal. > 4. Use a compile time flag USE_LIBPQ to switch between libPQ > and socket. Why keep the socket stuff? The whole point is to get rid of it and the associated complexity and rely on libpq. Regards, Dave.
We too don't want to do so. However until the testing of new libpq odbc driver is completed, the user can have an option of using socket code or libpq code. Once the new libpq odbc driver is stable we can get rid of the socket stuff. Regards, Siva Kumar.K -----Original Message----- From: Dave Page [mailto:dpage@vale-housing.co.uk] Sent: Tuesday, June 07, 2005 3:01 PM To: Sivakumar K; pgman@candle.pha.pa.us; fuerth@sqlpower.ca Cc: jd@commandprompt.com; pgsql-odbc@postgresql.org Subject: RE: [ODBC] Frontend/Backend protocol 3.0 > -----Original Message----- > From: pgsql-odbc-owner@postgresql.org > [mailto:pgsql-odbc-owner@postgresql.org] On Behalf Of Sivakumar K > Sent: 07 June 2005 09:44 > To: pgman@candle.pha.pa.us; fuerth@sqlpower.ca > Cc: jd@commandprompt.com; pgsql-odbc@postgresql.org > Subject: Re: [ODBC] Frontend/Backend protocol 3.0 > > Hi all, > > In continuation to my previous mail, here is an overview on > the approach > that we have taken. We had a few design goals when we started on this > exercise. > > 1. ODBC driver should still support socket mode. > 2. Use if-defs minimally. > 3. The code change should be minimal. > 4. Use a compile time flag USE_LIBPQ to switch between libPQ > and socket. Why keep the socket stuff? The whole point is to get rid of it and the associated complexity and rely on libpq. Regards, Dave.
> -----Original Message----- > From: Sivakumar K [mailto:sivakumark@pervasive-postgres.com] > Sent: 07 June 2005 13:14 > To: Dave Page; pgman@candle.pha.pa.us; fuerth@sqlpower.ca > Cc: jd@commandprompt.com; pgsql-odbc@postgresql.org > Subject: RE: [ODBC] Frontend/Backend protocol 3.0 > > We too don't want to do so. However until the testing of new > libpq odbc > driver is completed, the user can have an option of using > socket code or > libpq code. > > Once the new libpq odbc driver is stable we can get rid of the socket > stuff. Past experience shows that 99.99% of users will use the precompiled binaries we put on the ftp site, and if they are marked beta they will not generally get used or tested at all (as we found with the Unicode version of the driver that I had to push to be the primary version before we saw anyone using it unless they had a very specific need). I agree that giving the option is sensible for the reason you give, however I think if anything it will reduce the testing that gets done. Regards, Dave.
On Jun 7, 2005, at 8:14 AM, Sivakumar K wrote: > We too don't want to do so. However until the testing of new libpq odbc > driver is completed, the user can have an option of using socket code > or > libpq code. > > Once the new libpq odbc driver is stable we can get rid of the socket > stuff. Sounds like I wasted four good days of effort last week. :) Two questions: Sivakumar: Will your upcoming libpq patch include support for getting the SQLSTATE codes from backend to the ODBC side? Dave: Will you commit Sivakumar's patch into the posqlodbc project? Regards, Jonathan Fuerth
> -----Original Message----- > From: pgsql-odbc-owner@postgresql.org > [mailto:pgsql-odbc-owner@postgresql.org] On Behalf Of Jonathan Fuerth > Sent: 07 June 2005 15:39 > To: Sivakumar K > Cc: <pgsql-odbc@postgresql.org> > Subject: Re: [ODBC] Frontend/Backend protocol 3.0 > > On Jun 7, 2005, at 8:14 AM, Sivakumar K wrote: > > > We too don't want to do so. However until the testing of > new libpq odbc > > driver is completed, the user can have an option of using > socket code > > or > > libpq code. > > > > Once the new libpq odbc driver is stable we can get rid of > the socket > > stuff. > > Sounds like I wasted four good days of effort last week. :) > > Two questions: > > Sivakumar: Will your upcoming libpq patch include support for getting > the SQLSTATE codes from backend to the ODBC side? > > Dave: Will you commit Sivakumar's patch into the posqlodbc project? Well, I'm dealing with Anoop Kumar who was working on this (I assume Sivakumar is a colleague), but yes, following review on the list if the patch looks OK I will commit it. Regards, Dave.