-----Original Message-----
From: "Tom Lane"<tgl@sss.pgh.pa.us>
Sent: 14/04/06 16:22:45
To: "Martijn van Oosterhout"<kleptog@svana.org>
Cc: "Greg Stark"<gsstark@mit.edu>, "Zeugswetter Andreas DCP SD"<ZeugswetterA@spardat.at>, "Dave Page"<dpage@vale-housing.co.uk>, "pgsql-hackers@postgresql.org"<pgsql-hackers@postgresql.org>, "Hiroshi Inoue"<inoue@tpf.co.jp>
Subject: Re: [HACKERS] Practical impediment to supporting multiple SSL libraries

> A fair question to ask is whether psqlODBC would consider
> going back to a non-hybrid implementation if these features did exist
> in libpq.

It's not something I want to spend any more time on, and Hiroshi made it quite clear on -odbc yesterday that he doesn't want libpq to become a requirement of psqlODBC (it's dynamically loaded atm, thus is optional).

Regards, Dave

-----Unmodified Original Message-----
Martijn van Oosterhout <kleptog@svana.org> writes:
> On Fri, Apr 14, 2006 at 10:42:33AM -0400, Greg Stark wrote:
>> As long as there's a defined wire protocol (and there will always be
>> one) then there's nothing wrong with what the psqlODBC driver is doing

> Well, the main motivation for this is that when a new version of the
> protocol appears, libpq will support it but psqlODBC won't. If libpq
> provides a way to get these small bits of the unparsed stream in a
> protocol independant way, then that problem goes away.

Greg's observation is correct, so maybe we are overthinking this
problem. A fair question to ask is whether psqlODBC would consider
going back to a non-hybrid implementation if these features did exist
in libpq.

> There are a number of other (primarily driver) projects that would
> benefit from being able to bypass the PGresult structure for storing
> data.

Please mention some specific examples. We need some examples as a
reality check.

regards, tom lane


---------------------------(end of broadcast)---------------------------
TIP 2: Don't 'kill -9' the postmaster

Dave Page wrote:
>
> -----Original Message----- From: "Tom Lane"<tgl@sss.pgh.pa.us> Sent:
> 14/04/06 16:22:45 To: "Martijn van Oosterhout"<kleptog@svana.org> Cc:
> "Greg Stark"<gsstark@mit.edu>, "Zeugswetter Andreas DCP
> SD"<ZeugswetterA@spardat.at>, "Dave Page"<dpage@vale-housing.co.uk>,
> "pgsql-hackers@postgresql.org"<pgsql-hackers@postgresql.org>, "Hiroshi
> Inoue"<inoue@tpf.co.jp> Subject: Re: [HACKERS] Practical impediment to
> supporting multiple SSL libraries
>
> > A fair question to ask is whether psqlODBC would consider
> > going back to a non-hybrid implementation if these features did exist
> > in libpq.
>
> It's not something I want to spend any more time on, and Hiroshi made
> it quite clear on -odbc yesterday that he doesn't want libpq to become
> a requirement of psqlODBC (it's dynamically loaded atm, thus is
> optional).

Hiroshi does not speak for the psqlODBC project. It is a community
project.

--
Bruce Momjian http://candle.pha.pa.us
EnterpriseDB http://www.enterprisedb.com

+ If your life is a hard drive, Christ can be your backup. +

---------------------------(end of broadcast)---------------------------
TIP 9: In versions below 8.0, the planner will ignore your desire to
choose an index scan if your joining column's datatypes do not
match

> > It's not something I want to spend any more time on, and Hiroshi made
> > it quite clear on -odbc yesterday that he doesn't want libpq to become
> > a requirement of psqlODBC (it's dynamically loaded atm, thus is
> > optional).
>
> Hiroshi does not speak for the psqlODBC project. It is a community
> project.

Well yes it is a community project, but whoever is doing the development
is going to make the decision on what direction to go.

Sincerely,

Joshua D. Drake

>
> --
> Bruce Momjian http://candle.pha.pa.us
> EnterpriseDB http://www.enterprisedb.com
>
> + If your life is a hard drive, Christ can be your backup. +
>
> ---------------------------(end of broadcast)---------------------------
> TIP 9: In versions below 8.0, the planner will ignore your desire to
> choose an index scan if your joining column's datatypes do not
> match
>
--

=== The PostgreSQL Company: Command Prompt, Inc. ===
Sales/Support: +1.503.667.4564 || 24x7/Emergency: +1.800.492.2240
Providing the most comprehensive PostgreSQL solutions since 1997
http://www.commandprompt.com/





---------------------------(end of broadcast)---------------------------
TIP 1: if posting/reading through Usenet, please send an appropriate
subscribe-nomail command to majordomo@postgresql.org so that your
message can get through to the mailing list cleanly