Martijn van Oosterhout wrote:
On Thu, Apr 13, 2006 at 09:00:10PM -0400, Tom Lane wrote:
Probably there would need to be at least three callbacks involved:
one for setup, called just after the tuple descriptor info has been
received; one for per-field data receipt, and one for per-tuple
Martijn van Oosterhout wrote:
On Fri, Apr 14, 2006 at 04:53:53PM +0200, Martijn van Oosterhout wrote:
Sounds really good.
snip
There's a message on the pgsql-odbc mailing list[1] with some reasons
for not using libpq:
1. The driver sets some session default parameters(DateStyle,
Well, the psqlODBC driver apparently ran into a number of problems
with
libpq that resulted in them not using it for their purpose.
Given libpq primary purpose is to connect to PostgreSQL, it failing at
that is
something that should be fixed.
I think you are forgetting, that e.g. a JDBC
Zeugswetter Andreas DCP SD [EMAIL PROTECTED] writes:
Well, the psqlODBC driver apparently ran into a number of problems with
libpq that resulted in them not using it for their purpose. Given libpq
primary purpose is to connect to PostgreSQL, it failing at that is
something that should be
Greg Stark [EMAIL PROTECTED] writes:
Zeugswetter Andreas DCP SD [EMAIL PROTECTED] writes:
Well, the psqlODBC driver apparently ran into a number of problems with
libpq that resulted in them not using it for their purpose. Given libpq
primary purpose is to connect to PostgreSQL, it
On Thu, Apr 13, 2006 at 09:00:10PM -0400, Tom Lane wrote:
Probably there would need to be at least three callbacks involved:
one for setup, called just after the tuple descriptor info has been
received; one for per-field data receipt, and one for per-tuple
operations (called after all the
On Fri, Apr 14, 2006 at 10:42:33AM -0400, Greg Stark wrote:
Hm, now that I've had some sleep I think I see where you're going with this.
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 and having a
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
On Fri, Apr 14, 2006 at 04:53:53PM +0200, Martijn van Oosterhout wrote:
Sounds really good.
snip
There's a message on the pgsql-odbc mailing list[1] with some reasons
for not using libpq:
1. The driver sets some session default parameters(DateStyle,
client_encoding etc) using start-up
@postgresql.org, Hiroshi
Inoueinoue@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
-hackers@postgresql.org, Hiroshi
Inoueinoue@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
@postgresql.orgpgsql-hackers@postgresql.org,
inoue@tpf.co.jpinoue@tpf.co.jp
Subject: Re: [HACKERS] Practical impediment to supporting multiple SSL libraries
Hiroshi does not speak for the psqlODBC project. It is a community
project.
I am well aware of that, but as he is by far the most
Dave Page wrote:
Hiroshi does not speak for the psqlODBC project. It is a community
project.
I am well aware of that, but as he is by far the most experienced and
productive ODBC developer we have it would not be particularly sensible
to not give his opinion the weight it deserves -
* Tom Lane ([EMAIL PROTECTED]) wrote:
Please mention some specific examples. We need some examples as a
reality check.
Just took a look through a couple of Debian packages which depend on
libpq4:
libpam-pgsql: pam_pgsql.c, line 473 it uses PQgetvalue() as one would
expect, but doesn't
@postgresql.orgpgsql-hackers@postgresql.org,
inoue@tpf.co.jpinoue@tpf.co.jp
Subject: Re: [HACKERS] Practical impediment to supporting multiple SSL libraries
Right, sure he has weight. It is the concept that If Hiroshi doesn't
want it, it isn't going to happen, that I objected to.
I don't believe
On Fri, Apr 14, 2006 at 11:22:23AM -0400, Tom Lane wrote:
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.
Well, it is an issue.
Martijn van Oosterhout kleptog@svana.org writes:
Perhaps a far easier approach would be to indeed just have a hijack
interface that provides read/write over whatever protocol libpq
negotiated.
Well, there's a precedent to look at: the original implementation of
COPY mode was pretty nearly
On Fri, Apr 14, 2006 at 01:05:11PM -0400, Tom Lane wrote:
Martijn van Oosterhout kleptog@svana.org writes:
Perhaps a far easier approach would be to indeed just have a hijack
interface that provides read/write over whatever protocol libpq
negotiated.
Well, there's a precedent to look at:
Stephen Frost [EMAIL PROTECTED] writes:
Another thought along these lines: Perhaps a 'PQgettuple' which can be
used to process one tuple at a time. This would be used in an ASYNC
fashion and libpq just wouldn't read/accept more than a tuple's worth
each time, which it could do into a fixed
* Greg Stark ([EMAIL PROTECTED]) wrote:
Stephen Frost [EMAIL PROTECTED] writes:
Another thought along these lines: Perhaps a 'PQgettuple' which can be
used to process one tuple at a time. This would be used in an ASYNC
fashion and libpq just wouldn't read/accept more than a tuple's worth
Stephen Frost [EMAIL PROTECTED] writes:
Right... As I mentioned, the application can use cursors to
*work-around* this foolishness in libpq but that doesn't really make it
any less silly.
Before you define libpq's behavior as foolishness, you really ought to
have a watertight semantics for
* Tom Lane ([EMAIL PROTECTED]) wrote:
Stephen Frost [EMAIL PROTECTED] writes:
Right... As I mentioned, the application can use cursors to
*work-around* this foolishness in libpq but that doesn't really make it
any less silly.
Before you define libpq's behavior as foolishness, you really
On Wed, Apr 12, 2006 at 05:00:17PM -0400, Tom Lane wrote:
Issuer (name and certificate), validity dates, basic constraints, key
usage, posslby fingerprint.
I think that way madness lies --- do we really want to commit to
re-inventing an SSL API that will cover anything someone might want
On Wed, Apr 12, 2006 at 05:25:47PM +0100, Dave Page wrote:
The driver implements all versions of the wire protocol itself, but if
libpq is available at runtime (it will dynamically load it on platforms
that support it) it can use it for connection setup so features like SSL
can be provided
-Original Message-
From: Martijn van Oosterhout [mailto:[EMAIL PROTECTED]
Sent: 13 April 2006 07:58
To: Dave Page
Cc: pgsql-hackers@postgresql.org; Hiroshi Inoue
Subject: Re: [HACKERS] Practical impediment to supporting
multiple SSL libraries
On Wed, Apr 12, 2006 at 05:25
On Thu, Apr 13, 2006 at 08:48:54AM +0100, Dave Page wrote:
Well, we had a pure custom implementation of the protocol, had a pure
libpq based version and after much discussion decided that the best
version of all was the hybrid as it allowed us to hijack features like
SSL, Kerberos, pgpass et
-Original Message-
From: Martijn van Oosterhout [mailto:[EMAIL PROTECTED]
Sent: 13 April 2006 09:15
To: Dave Page
Cc: pgsql-hackers@postgresql.org; Hiroshi Inoue
Subject: Re: [HACKERS] Practical impediment to supporting
multiple SSL libraries
On Thu, Apr 13, 2006 at 08:48
* Martijn van Oosterhout (kleptog@svana.org) wrote:
On Thu, Apr 13, 2006 at 08:48:54AM +0100, Dave Page wrote:
Well, we had a pure custom implementation of the protocol, had a pure
libpq based version and after much discussion decided that the best
version of all was the hybrid as it
On Thu, Apr 13, 2006 at 06:44:12AM -0400, Stephen Frost wrote:
Instead of having it hijack the libpq connection and implement the
wireline protocol itself, why don't we work on fixing the problems (such
as the double-copying that libpq requires) in libpq to allow the driver
(and others!) to
-Original Message-
From: Stephen Frost [mailto:[EMAIL PROTECTED]
Sent: 13 April 2006 11:44
To: Martijn van Oosterhout
Cc: Dave Page; pgsql-hackers@postgresql.org; Hiroshi Inoue
Subject: Re: [HACKERS] Practical impediment to supporting
multiple SSL libraries
Instead of having
-Original Message-
From: Martijn van Oosterhout [mailto:[EMAIL PROTECTED]
Sent: 13 April 2006 11:54
To: Dave Page; pgsql-hackers@postgresql.org; Hiroshi Inoue
Subject: Re: [HACKERS] Practical impediment to supporting
multiple SSL libraries
On Thu, Apr 13, 2006 at 06:44:12AM
On Thu, Apr 13, 2006 at 12:12:25PM +0100, Dave Page wrote:
Ok. I'm not sure what this double copying you're referring
to is,
The libpq driver copies results out of the PGresult struct into the
internal QueryResult classes. With libpq out of the loop, data can go
straight from the wire
-Original Message-
From: Martijn van Oosterhout [mailto:[EMAIL PROTECTED]
Sent: 13 April 2006 12:34
To: Dave Page
Cc: pgsql-hackers@postgresql.org; Hiroshi Inoue
Subject: Re: [HACKERS] Practical impediment to supporting
multiple SSL libraries
However, w.r.t. the copying
* Dave Page (dpage@vale-housing.co.uk) wrote:
This has been the subject of discussion for many months and the
concencus was that the most effective approach was the hybrid one which
has now been moved into CVS tip. Those involved are fully aware of the
maintenance issues of implementing the
-Original Message-
From: Stephen Frost [mailto:[EMAIL PROTECTED]
Sent: 13 April 2006 12:56
To: Dave Page
Cc: Martijn van Oosterhout; pgsql-hackers@postgresql.org;
Hiroshi Inoue
Subject: Re: [HACKERS] Practical impediment to supporting
multiple SSL libraries
* Martijn van Oosterhout (kleptog@svana.org) wrote:
On Thu, Apr 13, 2006 at 12:12:25PM +0100, Dave Page wrote:
Ok. I'm not sure what this double copying you're referring
to is,
The libpq driver copies results out of the PGresult struct into the
internal QueryResult classes. With
On Thu, Apr 13, 2006 at 12:48:06PM +0100, Dave Page wrote:
Anyhoo, as I've said, that approach has now been abandoned anyway in
favour of Hiroshi's, so it's him you'd need to convince to change. The
rest of us have only just started re-learning the code.
Well, I quickly scanned the code in CVS
* Dave Page (dpage@vale-housing.co.uk) wrote:
What does the wireline protocol implementation in the ODBC
driver do that it can't get through libpq? I can certainly
understand the double-copying issue (I complained about that
myself when first starting to use libpq) but I think that
* Martijn van Oosterhout (kleptog@svana.org) wrote:
Well, I quickly scanned the code in CVS to see what I could find out.
Wow, that was quick. :)
So in fact what you really want is libpq as a protocol decoder but want
to manage your resultset yourself. And you want to be able to let users
-Original Message-
From: Stephen Frost [mailto:[EMAIL PROTECTED]
Sent: 13 April 2006 14:03
To: Martijn van Oosterhout
Cc: Dave Page; pgsql-hackers@postgresql.org; Hiroshi Inoue
Subject: Re: [HACKERS] Practical impediment to supporting
multiple SSL libraries
* Martijn van
On Thu, Apr 13, 2006 at 08:32:34AM -0400, Stephen Frost wrote:
* Martijn van Oosterhout (kleptog@svana.org) wrote:
Hmm, the simplest improvement I can think of is one where you
register a callback that libpq calls whenever it has received a new
tuple.
You wouldn't want it on every tuple
* Martijn van Oosterhout (kleptog@svana.org) wrote:
On Thu, Apr 13, 2006 at 08:32:34AM -0400, Stephen Frost wrote:
You wouldn't want it on every tuple as that'd get expensive through
function calls.
Why not? Internally we call pqAddTuple for every tuple, calling a user
function instead is
Martijn van Oosterhout kleptog@svana.org writes:
Right. Would you see value in a more formal libpq hijack-me interface
that would support making the initial connection and then handing off
the rest to something else?
I think this would just be busywork... the way ODBC is doing it seems
fine to
Martijn van Oosterhout kleptog@svana.org writes:
On Thu, Apr 13, 2006 at 12:12:25PM +0100, Dave Page wrote:
Ok. I'm not sure what this double copying you're referring
to is,
The libpq driver copies results out of the PGresult struct into the
internal QueryResult classes. With
* Martijn van Oosterhout (kleptog@svana.org) wrote:
Why not? Internally we call pqAddTuple for every tuple, calling a user
function instead is hardly going to be more expensive. Also, I was
thinking of the situation where the user function could set a flag
so the eventual caller of (perhaps)
On Thu, Apr 13, 2006 at 09:34:10AM -0400, Stephen Frost wrote:
* Martijn van Oosterhout (kleptog@svana.org) wrote:
Except in the case of psqlODBC, it wants to be able to malloc/free()
each field, which your method doesn't solve. Also, it doesn't solve the
duplicate memory use, nor the
* Greg Stark ([EMAIL PROTECTED]) wrote:
Martijn van Oosterhout kleptog@svana.org writes:
Hmm, the simplest improvement I can think of is one where you
register a callback that libpq calls whenever it has received a new
tuple.
That could be useful for applications but I think a driver
On Thu, Apr 13, 2006 at 11:14:57AM -0400, Greg Stark wrote:
That could be useful for applications but I think a driver really wants to
retain control of the flow of control. To make use of a callback it would have
to have an awkward dance of calling whatever function gives libpq license to
* Martijn van Oosterhout (kleptog@svana.org) wrote:
Right, I didn't understand that you meant to be doing this
synchronously, as the data came in. I thought it was just another way
of retreiving the data already received. But given that a stated reason
that psqlODBC didn't use the libpq
Stephen Frost [EMAIL PROTECTED] writes:
I can see how having a callback would be useful though I think for a
good number of cases it's just going to be populating a memory region
with it and we could cover that common case by providing an API for
exactly that.
We already have that: it's
* Tom Lane ([EMAIL PROTECTED]) wrote:
Stephen Frost [EMAIL PROTECTED] writes:
I can see how having a callback would be useful though I think for a
good number of cases it's just going to be populating a memory region
with it and we could cover that common case by providing an API for
On Thu, Apr 13, 2006 at 11:54:33AM -0400, Stephen Frost wrote:
snip
Sure you could but you're forced to do more copying around of the data
(copy into the PGresAttValue, copy out of it into your structure array).
If you want something more complex then a callback makes more sense but
I'm of
On Thu, Apr 13, 2006 at 12:02:56PM -0400, Greg Stark wrote:
There's nothing wrong with a callback interface for applications. They can
generally have the callback function update the display or output to a file or
whatever they're planning to do with the data.
However drivers don't generally
Greg Stark [EMAIL PROTECTED] writes:
I think there's some confusion about what problem this is aiming to solve. I
thought the primary problem ODBC and other drivers have is just that they want
to be able to fetch whatever records are available instead of waiting for the
entire query results to
* Tom Lane ([EMAIL PROTECTED]) wrote:
Stephen Frost [EMAIL PROTECTED] writes:
It's only the functional equivalent when you think all the world is a
Postgres app, which is just not the case.
If we are dumping data into a simple memory block in a format dictated
by libpq, then we haven't
* Greg Stark ([EMAIL PROTECTED]) wrote:
Tom Lane [EMAIL PROTECTED] writes:
So instead, you'd prefer to *always* store partial tuples in a temporary
area, thereby making sure the independent-field-conversions case has
performance just as bad as the dependent-conversions case.
I can't
Tom Lane [EMAIL PROTECTED] writes:
Greg Stark [EMAIL PROTECTED] writes:
I think there's some confusion about what problem this is aiming to solve. I
thought the primary problem ODBC and other drivers have is just that they
want
to be able to fetch whatever records are available instead
* Greg Stark ([EMAIL PROTECTED]) wrote:
Tom Lane [EMAIL PROTECTED] writes:
Greg Stark [EMAIL PROTECTED] writes:
I think there's some confusion about what problem this is aiming to
solve. I
thought the primary problem ODBC and other drivers have is just that they
want
to be able
On Thu, Apr 13, 2006 at 03:42:44PM -0400, Stephen Frost wrote:
You seem to be talking about a much broader set of problems to solve.
I'd like to improve the API in general to cover a set of use-cases that
I've run into quite a few times (and apparently some others have too as
other DBs
Martijn van Oosterhout wrote:
-- Start of PGP signed section.
On Thu, Apr 13, 2006 at 03:42:44PM -0400, Stephen Frost wrote:
You seem to be talking about a much broader set of problems to solve.
I'd like to improve the API in general to cover a set of use-cases that
I've run into quite
Greg Stark [EMAIL PROTECTED] writes:
Tom Lane [EMAIL PROTECTED] writes:
No, that's not what I'm thinking about at all, and I don't think Martijn
is either. The point here is that ODBC wants to store the resultset in
a considerably different format from what libpq natively provides, and
we'd
Stephen Frost wrote:
* Martijn van Oosterhout (kleptog@svana.org) wrote:
On Thu, Apr 13, 2006 at 08:48:54AM +0100, Dave Page wrote:
Well, we had a pure custom implementation of the protocol, had a pure
libpq based version and after much discussion decided that the best
version of all
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of
Martijn van Oosterhout
Sent: 12 April 2006 16:48
To: pgsql-hackers@postgresql.org
Subject: [HACKERS] Practical impediment to supporting
multiple SSL libraries
Just quickly going through what
On Wed, Apr 12, 2006 at 05:03:32PM +0100, Dave Page wrote:
about the declaration of PQgetssl
The next version of psqlODBC (that has just gone into CVS tip after
months of work and debate) uses it, and would break almost completely
should it be removed, therefore any backwards incompatible
-Original Message-
From: Martijn van Oosterhout [mailto:[EMAIL PROTECTED]
Sent: 12 April 2006 17:15
To: Dave Page
Cc: pgsql-hackers@postgresql.org
Subject: Re: [HACKERS] Practical impediment to supporting
multiple SSL libraries
On Wed, Apr 12, 2006 at 05:03:32PM +0100, Dave
Martijn van Oosterhout kleptog@svana.org writes:
1. Changing it to always return (void*), irrespective of SSL
...
Personally, I'm in favour of 1, because then we can get rid of the
#include for openssl, so users don't have to have openssl headers
installed to compile postgresql programs.
I
Tom Lane wrote:
Martijn van Oosterhout kleptog@svana.org writes:
1. Changing it to always return (void*), irrespective of SSL
...
Personally, I'm in favour of 1, because then we can get rid of the
#include for openssl, so users don't have to have openssl headers
installed to compile postgresql
* Tom Lane ([EMAIL PROTECTED]) wrote:
Martijn van Oosterhout kleptog@svana.org writes:
1. Changing it to always return (void*), irrespective of SSL
...
Personally, I'm in favour of 1, because then we can get rid of the
#include for openssl, so users don't have to have openssl headers
* Andreas Pflug ([EMAIL PROTECTED]) wrote:
I wonder if there are apps that actually use the ssl pointer, beyond
detection of encrypted connections. So interpreting the result as bool
would be sufficient.
I'm not sure if there are apps out there which use it for anything but a
bool but
On Wed, Apr 12, 2006 at 01:42:51PM -0400, Stephen Frost wrote:
* Andreas Pflug ([EMAIL PROTECTED]) wrote:
I wonder if there are apps that actually use the ssl pointer, beyond
detection of encrypted connections. So interpreting the result as bool
would be sufficient.
I'm not sure if
On Wed, Apr 12, 2006 at 12:32:01PM -0400, Tom Lane wrote:
There is a more serious issue here though: if we allow more than one SSL
library, what exactly can an application safely do with the returned
pointer? It strikes me as very dangerous for the app to assume it knows
which SSL library is
There is a more serious issue here though: if we allow more
than one
SSL library, what exactly can an application safely do with the
returned pointer? It strikes me as very dangerous for the app to
assume it knows which SSL library is underneath libpq. It's not at
all hard to
On Wed, Apr 12, 2006 at 08:14:58PM +0200, Magnus Hagander wrote:
Other than DN and CN, what else would people want?
Issuer (name and certificate), validity dates, basic constraints, key
usage, posslby fingerprint.
GnuTLS handles this with just one function:
gnutls_x509_crt_get_dn_by_oid(
Magnus Hagander [EMAIL PROTECTED] writes:
Other than DN and CN, what else would people want?
Issuer (name and certificate), validity dates, basic constraints, key
usage, posslby fingerprint.
I think that way madness lies --- do we really want to commit to
re-inventing an SSL API that will
Martijn van Oosterhout wrote:
On Wed, Apr 12, 2006 at 05:03:32PM +0100, Dave Page wrote:
about the declaration of PQgetssl
The next version of psqlODBC (that has just gone into CVS tip after
months of work and debate) uses it, and would break almost completely
should it be removed, therefore
75 matches
Mail list logo
