[ODBC] Frontend/Backend protocol 3.0

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
22 messages Options
12
Reply | Threaded
Open this post in threaded view
|

[ODBC] Frontend/Backend protocol 3.0

Jonathan Fuerth
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
Reply | Threaded
Open this post in threaded view
|

Re: Frontend/Backend protocol 3.0

Andrei Gaspar
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


---------------------------(end of broadcast)---------------------------
TIP 5: Have you checked our extensive FAQ?

               http://www.postgresql.org/docs/faq
Reply | Threaded
Open this post in threaded view
|

Re: Frontend/Backend protocol 3.0

Jonathan Fuerth
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


---------------------------(end of broadcast)---------------------------
TIP 8: explain analyze is your friend
Reply | Threaded
Open this post in threaded view
|

Re: Frontend/Backend protocol 3.0

Bruce Momjian-2
In reply to this post by 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
  [hidden email]               |  (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
Reply | Threaded
Open this post in threaded view
|

Re: Frontend/Backend protocol 3.0

Jonathan Fuerth
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


---------------------------(end of broadcast)---------------------------
TIP 3: if posting/reading through Usenet, please send an appropriate
      subscribe-nomail command to [hidden email] so that your
      message can get through to the mailing list cleanly
Reply | Threaded
Open this post in threaded view
|

Re: Frontend/Backend protocol 3.0

Jonathan Fuerth
In reply to this post by Bruce Momjian-2
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
Reply | Threaded
Open this post in threaded view
|

Re: Frontend/Backend protocol 3.0

Bruce Momjian-2

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
  [hidden email]               |  (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
Reply | Threaded
Open this post in threaded view
|

Re: Frontend/Backend protocol 3.0

Jeff Eckermann
--- Bruce Momjian <[hidden email]> 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
>   [hidden email]               |  (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
Reply | Threaded
Open this post in threaded view
|

Re: Frontend/Backend protocol 3.0

Bruce Momjian-2
Jeff Eckermann wrote:
> --- Bruce Momjian <[hidden email]> 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
> >   [hidden email]               |  (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
  [hidden email]               |  (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
Reply | Threaded
Open this post in threaded view
|

Re: Frontend/Backend protocol 3.0

Jonathan Fuerth
In reply to this post by Bruce Momjian-2
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


---------------------------(end of broadcast)---------------------------
TIP 7: don't forget to increase your free space map settings
Reply | Threaded
Open this post in threaded view
|

Re: Frontend/Backend protocol 3.0

Bruce Momjian-2
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
  [hidden email]               |  (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 9: the planner will ignore your desire to choose an index scan if your
      joining column's datatypes do not match
Reply | Threaded
Open this post in threaded view
|

Re: Frontend/Backend protocol 3.0

Joshua D. Drake

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

---------------------------(end of broadcast)---------------------------
TIP 5: Have you checked our extensive FAQ?

               http://www.postgresql.org/docs/faq
Reply | Threaded
Open this post in threaded view
|

Re: Frontend/Backend protocol 3.0

Jonathan Fuerth
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


---------------------------(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
Reply | Threaded
Open this post in threaded view
|

Re: Frontend/Backend protocol 3.0

Bruce Momjian-2
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
  [hidden email]               |  (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
Reply | Threaded
Open this post in threaded view
|

Re: Frontend/Backend protocol 3.0

Sivakumar K
In reply to this post by Jonathan Fuerth


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: [hidden email]
[mailto:[hidden email]] On Behalf Of Bruce Momjian
Sent: Tuesday, June 07, 2005 5:05 AM
To: Jonathan Fuerth
Cc: Joshua D. Drake; [hidden email]
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
  [hidden email]               |  (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


---------------------------(end of broadcast)---------------------------
TIP 5: Have you checked our extensive FAQ?

               http://www.postgresql.org/docs/faq
Reply | Threaded
Open this post in threaded view
|

Problem while using Refcursors in Postgres with .NET

selvaraj balasundaram
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

Reply | Threaded
Open this post in threaded view
|

Re: Frontend/Backend protocol 3.0

Sivakumar K
In reply to this post by Jonathan Fuerth
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: '[hidden email]'; '[hidden email]'
Cc: '[hidden email]'; '[hidden email]'
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: [hidden email]
[mailto:[hidden email]] On Behalf Of Bruce Momjian
Sent: Tuesday, June 07, 2005 5:05 AM
To: Jonathan Fuerth
Cc: Joshua D. Drake; [hidden email]
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
  [hidden email]               |  (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


---------------------------(end of broadcast)---------------------------
TIP 6: Have you searched our list archives?

               http://archives.postgresql.org
Reply | Threaded
Open this post in threaded view
|

Re: Frontend/Backend protocol 3.0

Dave Page
In reply to this post by Jonathan Fuerth
 

> -----Original Message-----
> From: [hidden email]
> [mailto:[hidden email]] On Behalf Of Sivakumar K
> Sent: 07 June 2005 09:44
> To: [hidden email]; [hidden email]
> Cc: [hidden email]; [hidden email]
> 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.

---------------------------(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
Reply | Threaded
Open this post in threaded view
|

Re: Frontend/Backend protocol 3.0

Sivakumar K
In reply to this post by Jonathan Fuerth
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:[hidden email]]
Sent: Tuesday, June 07, 2005 3:01 PM
To: Sivakumar K; [hidden email]; [hidden email]
Cc: [hidden email]; [hidden email]
Subject: RE: [ODBC] Frontend/Backend protocol 3.0

 

> -----Original Message-----
> From: [hidden email]
> [mailto:[hidden email]] On Behalf Of Sivakumar K
> Sent: 07 June 2005 09:44
> To: [hidden email]; [hidden email]
> Cc: [hidden email]; [hidden email]
> 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.

---------------------------(end of broadcast)---------------------------
TIP 5: Have you checked our extensive FAQ?

               http://www.postgresql.org/docs/faq
Reply | Threaded
Open this post in threaded view
|

Re: Frontend/Backend protocol 3.0

Dave Page
In reply to this post by Jonathan Fuerth
 

> -----Original Message-----
> From: Sivakumar K [mailto:[hidden email]]
> Sent: 07 June 2005 13:14
> To: Dave Page; [hidden email]; [hidden email]
> Cc: [hidden email]; [hidden email]
> 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.

---------------------------(end of broadcast)---------------------------
TIP 3: if posting/reading through Usenet, please send an appropriate
      subscribe-nomail command to [hidden email] so that your
      message can get through to the mailing list cleanly
12