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-tupl
Martijn van Oosterhout wrote:
>On Fri, Apr 14, 2006 at 04:53:53PM +0200, Martijn van Oosterhout wrote:
>
>
>>Sounds really good.
>>
>>
>
>
>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(DateSt
* 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"
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
* 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'
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 f
On Fri, Apr 14, 2006 at 01:05:11PM -0400, Tom Lane wrote:
> Martijn van Oosterhout 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 orig
Martijn van Oosterhout 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 exactly that. And
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 issu
IL PROTECTED]>,
"pgsql-hackers@postgresql.org",
"inoue@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 happ
* 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 actual
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
IL PROTECTED]>,
"pgsql-hackers@postgresql.org",
"inoue@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
TED]>, "Dave Page",
> "pgsql-hackers@postgresql.org", "Hiroshi
> Inoue" Subject: Re: [HACKERS] Practical impediment to
> supporting multiple SSL libraries
>
> > A fair question to ask is whether psqlODBC would consider
> > going back to a no
uot;pgsql-hackers@postgresql.org", "Hiroshi
Inoue"
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
On Fri, Apr 14, 2006 at 04:53:53PM +0200, Martijn van Oosterhout wrote:
> Sounds really good.
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 message.
Martijn van Oosterhout 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 ve
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
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 f
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 Po
"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 tha
> 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
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
>>>
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,
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 in
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
* 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
> > >
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 availa
* 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 c
* 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 h
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 resul
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 follow that reasoning.
I think there's som
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 gener
On Thu, Apr 13, 2006 at 11:54:33AM -0400, Stephen Frost wrote:
> 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 th
Stephen Frost <[EMAIL PROTECTED]> writes:
> * Tom Lane ([EMAIL PROTECTED]) wrote:
>> The only reason I can see for offering any new feature in this area is
>> to cater to apps that want to transform the data representation
>> on-the-fly, not merely dump it into an area that will be the functional
>
* 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 fo
Martijn van Oosterhout writes:
> 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 calli
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
* 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 int
Martijn van Oosterhout writes:
> ...you seem to be suggesting that all the data be stored in one big memory
> block at resultset.
I didn't like that either; it assumes far too much about what the
application needs to do. I think what's wanted is a callback hook
that lets the app decide where and
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
>
* Greg Stark ([EMAIL PROTECTED]) wrote:
> Martijn van Oosterhout 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 really wants
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
* 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
Martijn van Oosterhout 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 libpq
Martijn van Oosterhout 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 me. In any
* 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 ins
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 ever
> -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
> m
* 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
>
* 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 t
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 C
* 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 cl
> -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
* 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: 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
>
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 t
> -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
> -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 l
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
* 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
> -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: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 e
> -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: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
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 w
Martijn van Oosterhout wrote:
>On Wed, Apr 12, 2006 at 05:03:32PM +0100, Dave Page wrote:
>
>
>
>
>>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 incompat
"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 w
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_oi
> > 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 h
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
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 sur
* 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 ther
* Tom Lane ([EMAIL PROTECTED]) wrote:
> Martijn van Oosterhout 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
Tom Lane wrote:
Martijn van Oosterhout 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 li
Martijn van Oosterhout 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 like that too.
> -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,
On Wed, Apr 12, 2006 at 05:03:32PM +0100, Dave Page wrote:
> 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 change should
> be avoided imho. An
> -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 thro
79 matches
Mail list logo
