Re: [HACKERS] libpq connection strings: control over the cipher suites?

On 11/09/2017 03:17 PM, Michael Paquier wrote: > On Fri, Nov 10, 2017 at 2:53 AM, Joe Conway wrote: >> On 11/09/2017 03:27 AM, Graham Leggett wrote: >>> Is there a parameter or mechanism for setting the required ssl cipher list >>> from the client side? >> >> I don't believe

Re: [HACKERS] libpq connection strings: control over the cipher suites?

On Fri, Nov 10, 2017 at 2:53 AM, Joe Conway wrote: > On 11/09/2017 03:27 AM, Graham Leggett wrote: >> Is there a parameter or mechanism for setting the required ssl cipher list >> from the client side? > > I don't believe so. That is controlled by ssl_ciphers, which requires

Re: [HACKERS] libpq connection strings: control over the cipher suites?

On 11/09/2017 03:27 AM, Graham Leggett wrote: > Is there a parameter or mechanism for setting the required ssl cipher list > from the client side? I don't believe so. That is controlled by ssl_ciphers, which requires a restart in order to change.

Re: protocol version negotiation (Re: [HACKERS] Libpq PGRES_COPY_BOTH - version compatibility)

On Thu, Jun 29, 2017 at 7:29 PM, Satyanarayana Narlapuram wrote: > -Original Message- The formatting of this message differs from the style normally used on this mailing list, and is hard to read. > 2. If the client version is anything other than

Re: protocol version negotiation (Re: [HACKERS] Libpq PGRES_COPY_BOTH - version compatibility)

On 29 June 2017 at 20:18, Robert Haas wrote: > I'm not sure if non-critical is exactly the right terminology. What > we want to do is distinguish between things that are intended as > protocol-level options vs. things that are intended as GUCs. We probably also need to

Re: protocol version negotiation (Re: [HACKERS] Libpq PGRES_COPY_BOTH - version compatibility)

x.net>; Magnus Hagander <mag...@hagander.net>; PostgreSQL-development <pgsql-hackers@postgresql.org> Subject: Re: protocol version negotiation (Re: [HACKERS] Libpq PGRES_COPY_BOTH - version compatibility) > 1. The client sends a StartupMessage 3.x for version 3.x. We cou

Re: protocol version negotiation (Re: [HACKERS] Libpq PGRES_COPY_BOTH - version compatibility)

On Wed, Jun 28, 2017 at 10:27 PM, Tom Lane wrote: > Yeah. Back in the day I helped design the PNG image format, and one > of the better ideas in it was to make a distinction between critical and > noncritical chunks within a PNG file; that was exactly the idea you're >

Re: protocol version negotiation (Re: [HACKERS] Libpq PGRES_COPY_BOTH - version compatibility)

On 29 June 2017 at 12:23, Craig Ringer wrote: > It does. But I don't see anywhere that extra round trips have been discussed. Ah, right, they're implied by having the server respond with some downversion message and ignore input until the client sends a new startup

Re: protocol version negotiation (Re: [HACKERS] Libpq PGRES_COPY_BOTH - version compatibility)

On 29 June 2017 at 10:27, Tom Lane wrote: > Craig Ringer writes: >> On 29 June 2017 at 03:01, Robert Haas wrote: >>> It wouldn't be >>> so bad if unrecognized parameters were just ignored; the client would >>> know from the

Re: protocol version negotiation (Re: [HACKERS] Libpq PGRES_COPY_BOTH - version compatibility)

Craig Ringer writes: > On 29 June 2017 at 03:01, Robert Haas wrote: >> It wouldn't be >> so bad if unrecognized parameters were just ignored; the client would >> know from the ServerProtocolVersion (or ParameterStatus) message that >> server had

Re: protocol version negotiation (Re: [HACKERS] Libpq PGRES_COPY_BOTH - version compatibility)

On 29 June 2017 at 09:44, Craig Ringer wrote: > I > can't personally think of much right away that wouldn't work pretty > well in a follow-on message. Actually, I take that back, there's one thing that's bugged me for a while that wouldn't work well this way: determining

Re: protocol version negotiation (Re: [HACKERS] Libpq PGRES_COPY_BOTH - version compatibility)

On 29 June 2017 at 03:01, Robert Haas wrote: > One problem with that is that it means that the format of the > StartupMessage itself can never change, which I think is not a good > choice. The startup message could be immediately followed by another supplemental message,

Re: protocol version negotiation (Re: [HACKERS] Libpq PGRES_COPY_BOTH - version compatibility)

On Wed, Jun 28, 2017 at 1:47 PM, Tom Lane wrote: > Robert Haas writes: >> Here's my proposal: > >> - If the server receives a StartupMessage for v3.x where x > the >> version it knows, instead of just slamming the connection shut, it >> responds by

Re: protocol version negotiation (Re: [HACKERS] Libpq PGRES_COPY_BOTH - version compatibility)

Robert Haas writes: > Here's my proposal: > - If the server receives a StartupMessage for v3.x where x > the > version it knows, instead of just slamming the connection shut, it > responds by sending some new message (let's say, > NegotiateProtocolVersion) specifying the

protocol version negotiation (Re: [HACKERS] Libpq PGRES_COPY_BOTH - version compatibility)

On Mon, Mar 28, 2011 at 7:07 PM, Tom Lane wrote: > I wrote: >> Now if we had a track record showing that we could tweak the protocol >> version without causing problems, it'd be fine with me to do it for this >> usage. But we don't, and this particular case doesn't seem like

Re: [HACKERS] libpq Alternate Row Processor

On 2/13/17 8:46 AM, Kyle Gearhart wrote: profile_filler.txt 61,410,901 ???:_int_malloc [/usr/lib64/libc-2.17.so] 38,321,887 ???:_int_free [/usr/lib64/libc-2.17.so] 31,400,139 ???:pqResultAlloc [/usr/local/pgsql/lib/libpq.so.5.10] 22,839,505 ???:pqParseInput3

Re: [HACKERS] libpq Alternate Row Processor

On Mon, Feb 13, 2017 Merlin Moncure wrote: >A barebones callback mode ISTM is a complete departure from the classic >PGresult interface. This code is pretty unpleasant IMO: acct->abalance = *((int*)PQgetvalue(res, 0, i)); abalance = acct->__bswap_32(acct->abalance); > Your code is faster but

Re: [HACKERS] libpq Alternate Row Processor

On Mon, Feb 13, 2017 at 8:46 AM, Kyle Gearhart wrote: > On 2/9/17 7:15 PM, Jim Nasby wrote: >> Can you run a trace to see where all the time is going in the single row >> case? I don't see an obvious time-suck with a quick look through the code. >> It'd be

Re: [HACKERS] libpq Alternate Row Processor

On 2/9/17 7:15 PM, Jim Nasby wrote: > Can you run a trace to see where all the time is going in the single row > case? I don't see an obvious time-suck with a quick look through the code. > It'd be interesting to see how things change if you eliminate the filler > column from the SELECT.

Re: [HACKERS] libpq Alternate Row Processor

On 2/8/17 5:11 PM, Kyle Gearhart wrote: Overall, wall clock improves 24%. User time elapsed is a 430% improvement. About half the time is spent waiting on the IO with the callback. With the regular pqRowProcessor only about 16% of the time is spent waiting on IO. To wit...

Re: [HACKERS] libpq Alternate Row Processor

From: Tom Lane [mailto:t...@sss.pgh.pa.us]: > Kyle Gearhart writes: >> The guts of pqRowProcessor in libpq does a good bit of work to maintain the >> internal data structure of a PGresult. There are a few use cases where the >> caller doesn't need the ability to

Re: [HACKERS] libpq Alternate Row Processor

Kyle Gearhart writes: > The guts of pqRowProcessor in libpq does a good bit of work to maintain the > internal data structure of a PGresult. There are a few use cases where the > caller doesn't need the ability to access the result set row by row, column > by

Re: [HACKERS] libpq Alternate Row Processor

On 2/3/17 3:53 PM, Kyle Gearhart wrote: The guts of pqRowProcessor in libpq does a good bit of work to maintain the internal data structure of a PGresult. There are a few use cases where the caller doesn't need the ability to access the result set row by row, column by column using

Re: [HACKERS] libpq bad async behaviour

On 14 January 2015 at 08:40, Andres Freund and...@2ndquadrant.com wrote: I think that kind of solution isn't likely to be satisfying. The amount of porting work is just not going to be worth the cost. And it won't be easily hideable in the API at all as the callers will expect a normal fd.

Re: [HACKERS] libpq bad async behaviour

On 2015-01-14 08:32:19 -0500, Robert Haas wrote: On Fri, Jan 9, 2015 at 2:57 PM, Daurnimator q...@daurnimator.com wrote: I'm worried about libpq blocking in some circumstances; particularly around SSL renegotiations. This came up while writing an async postgres library for lua, I realised

Re: [HACKERS] libpq bad async behaviour

On Fri, Jan 9, 2015 at 2:57 PM, Daurnimator q...@daurnimator.com wrote: I'm worried about libpq blocking in some circumstances; particularly around SSL renegotiations. This came up while writing an async postgres library for lua, I realised that this code was dangerous:

Re: [HACKERS] libpq 9.4 requires /etc/passwd?

Christoph Berg c...@df7cb.de writes: Re: Tom Lane 2015-01-10 22432.1420915...@sss.pgh.pa.us So what I propose we do with this is patch HEAD and 9.4 only. We need to do *something* in 9.4 to address Christoph's complaint, and that branch is new enough that we can probably get away with changing

Re: [HACKERS] libpq 9.4 requires /etc/passwd?

Re: Tom Lane 2015-01-11 13609.1420998...@sss.pgh.pa.us The problem isn't present in 9.3 and earlier (at least with postfix-pgsql), so there's no need to go back further. I've committed a fix for this in HEAD and 9.4. I've just tested with the HEAD libpq and the issue is fixed. Thanks! In

Re: [HACKERS] libpq 9.4 requires /etc/passwd?

Bruce Momjian br...@momjian.us writes: On Fri, Jan 9, 2015 at 06:57:02PM -0500, Tom Lane wrote: Hmm ... actually, I'll bet it's not $HOME that's at issue, but the name of the user. Commit a4c8f14364c27508233f8a31ac4b10a4c90235a9 turned failure of pg_fe_getauthname() into a hard connection

Re: [HACKERS] libpq 9.4 requires /etc/passwd?

On Fri, Jan 09, 2015 at 06:57:02PM -0500, Tom Lane wrote: Commit a4c8f14364c27508233f8a31ac4b10a4c90235a9 turned failure of pg_fe_getauthname() into a hard connection failure, whereas previously it was harmless as long as the caller provided a username. I wonder if we shouldn't just revert

Re: [HACKERS] libpq 9.4 requires /etc/passwd?

Re: Tom Lane 2015-01-10 22432.1420915...@sss.pgh.pa.us So what I propose we do with this is patch HEAD and 9.4 only. We need to do *something* in 9.4 to address Christoph's complaint, and that branch is new enough that we can probably get away with changing officially-unsupported APIs. The

Re: [HACKERS] libpq 9.4 requires /etc/passwd?

Christoph Berg c...@df7cb.de writes: Re: Tom Lane 2015-01-10 22432.1420915...@sss.pgh.pa.us So what I propose we do with this is patch HEAD and 9.4 only. We need to do *something* in 9.4 to address Christoph's complaint, and that branch is new enough that we can probably get away with changing

Re: [HACKERS] libpq 9.4 requires /etc/passwd?

One other point here: I realized while testing my patch that it's actually impossible to provoke the failure mode Christoph is unhappy about in psql. You can only see it in an application that uses PQsetdb/PQsetdbLogin, which of course psql doesn't anymore. The reason is that in the PQconnect

Re: [HACKERS] libpq 9.4 requires /etc/passwd?

On Sat, Jan 10, 2015 at 02:02:54PM -0500, Tom Lane wrote: Not entirely sure what to do about this, but I predict this won't be the last complaint unless we find some way to improve test coverage in this area. Or perhaps we could turn PQsetdbLogin into a ***very*** thin wrapper around

Re: [HACKERS] libpq 9.4 requires /etc/passwd?

On Fri, Jan 9, 2015 at 06:57:02PM -0500, Tom Lane wrote: I wrote: Christoph Berg c...@df7cb.de writes: libpq wants the user home directory to find .pgpass and .pg_service.conf files, but apparently the behavior to require the existence of the passwd file (or nss equivalent) is new in

Re: [HACKERS] libpq 9.4 requires /etc/passwd?

Christoph Berg c...@df7cb.de writes: libpq wants the user home directory to find .pgpass and .pg_service.conf files, but apparently the behavior to require the existence of the passwd file (or nss equivalent) is new in 9.4. There is demonstrably no direct reference to /etc/passwd in the PG

Re: [HACKERS] libpq 9.4 requires /etc/passwd?

I wrote: Christoph Berg c...@df7cb.de writes: libpq wants the user home directory to find .pgpass and .pg_service.conf files, but apparently the behavior to require the existence of the passwd file (or nss equivalent) is new in 9.4. There is demonstrably no direct reference to /etc/passwd in

Re: [HACKERS] libpq 9.4 requires /etc/passwd?

On Fri, Jan 9, 2015 at 06:42:19PM -0500, Tom Lane wrote: Christoph Berg c...@df7cb.de writes: libpq wants the user home directory to find .pgpass and .pg_service.conf files, but apparently the behavior to require the existence of the passwd file (or nss equivalent) is new in 9.4. There

Re: [HACKERS] libpq pipelining

On Friday, December 05, 2014 12:22:38 PM Heikki Linnakangas wrote: Oh, that's what the PQgetLastQuery/PQgetNextQuery functions work! I didn't understand that before. I'd suggest renaming them to something like PQgetSentQuery() and PQgetResultQuery(). The first/last/next names made me think

Re: [HACKERS] libpq pipelining

On 12/05/2014 02:30 AM, Matt Newell wrote: The explanation of PQgetFirstQuery makes it sound pretty hard to match up the result with the query. You have to pay attention to PQisBusy. PQgetFirstQuery should also be valid after calling PQgetResult and then you don't have to worry about

Re: [HACKERS] libpq pipelining

On 12/04/2014 03:11 AM, Matt Newell wrote: The recent discussion about pipelining in the jodbc driver prompted me to look at what it would take for libpq. Great! I have a proof of concept patch working. The results are even more promising than I expected. While it's true that many

Re: [HACKERS] libpq pipelining

On 12/04/2014 05:08 PM, Heikki Linnakangas wrote: A good API is crucial for this. It should make it easy to write an application that does pipelining, and to handle all the error conditions in a predictable way. I'd suggest that you write the documentation first, before writing any code, so

Re: [HACKERS] libpq pipelining

On Thursday, December 04, 2014 10:30:46 PM Craig Ringer wrote: On 12/04/2014 05:08 PM, Heikki Linnakangas wrote: A good API is crucial for this. It should make it easy to write an application that does pipelining, and to handle all the error conditions in a predictable way. I'd suggest that

Re: [HACKERS] libpq pipelining

On Thu, Dec 4, 2014 at 4:11 PM, Matt Newell newe...@blur.com wrote: With the API i am proposing, only 2 new functions (PQgetFirstQuery, PQgetLastQuery) are required to be able to match each result to the query that caused it. Another function, PQgetNextQuery allows iterating through the

Re: [HACKERS] libpq pipelining

On Thursday, December 04, 2014 04:30:27 PM Claudio Freire wrote: On Thu, Dec 4, 2014 at 4:11 PM, Matt Newell newe...@blur.com wrote: With the API i am proposing, only 2 new functions (PQgetFirstQuery, PQgetLastQuery) are required to be able to match each result to the query that caused it.

Re: [HACKERS] libpq pipelining

On 12/04/2014 09:11 PM, Matt Newell wrote: With the API i am proposing, only 2 new functions (PQgetFirstQuery, PQgetLastQuery) are required to be able to match each result to the query that caused it. Another function, PQgetNextQuery allows iterating through the pending queries, and

Re: [HACKERS] libpq pipelining

On Thursday, December 04, 2014 11:39:02 PM Heikki Linnakangas wrote: Adding the ability to set a user supplied pointer on the PGquery struct might make it much easier for some frameworks, and other users might want a callback, but I don't think either are required. I don't like exposing

Re: [HACKERS] libpq pipelining

The explanation of PQgetFirstQuery makes it sound pretty hard to match up the result with the query. You have to pay attention to PQisBusy. PQgetFirstQuery should also be valid after calling PQgetResult and then you don't have to worry about PQisBusy, so I should probably change the

Re: [HACKERS] libpq-dev: pg_config_manual.h redefines CACHE_LINE_SIZE

On 2014-09-30 21:57:56 +0200, Christoph Berg wrote: Hi, there's a #define clash between pg_config_manual.h and FreeBSD's /usr/include/machine-amd64/param.h which also defines CACHE_LINE_SIZE. It's probably not really a PostgreSQL bug, but it seems easy enough to rename that definition now

Re: [HACKERS] libpq-dev: pg_config_manual.h redefines CACHE_LINE_SIZE

On Tue, Sep 30, 2014 at 12:57 PM, Christoph Berg m...@debian.org wrote: It's probably not really a PostgreSQL bug, but it seems easy enough to rename that definition now as it's only present in 9.4+. It's only used in one file, xlog.c: 375d8526f2900d0c377f44532f6d09ee06531f67 I agree. It

Re: [HACKERS] libpq-dev: pg_config_manual.h redefines CACHE_LINE_SIZE

On 2014-09-30 13:42:11 -0700, Peter Geoghegan wrote: On Tue, Sep 30, 2014 at 12:57 PM, Christoph Berg m...@debian.org wrote: It's probably not really a PostgreSQL bug, but it seems easy enough to rename that definition now as it's only present in 9.4+. It's only used in one file, xlog.c:

Re: [HACKERS] libpq connection status and closed fd

2014-09-22 10:42 GMT+04:00 Daniele Varrazzo daniele.varra...@gmail.com: Hello, a psycopg user is reporting [1] that the library is not marking the connection as closed and/or bad after certain errors, such as a connection timeout. He is emulating the error by closing the connection fd (I

Re: [HACKERS] libpq connection status and closed fd

On Mon, Sep 22, 2014 at 8:17 AM, Dmitriy Igrishin dmit...@gmail.com wrote: 2014-09-22 10:42 GMT+04:00 Daniele Varrazzo daniele.varra...@gmail.com: [2] https://gist.github.com/dvarrazzo/065f343c95f8ea67cf8f Why are you using close() instead of PQfinish()? Because I'm testing for an error,

Re: [HACKERS] libpq connection status and closed fd

2014-09-22 11:35 GMT+04:00 Daniele Varrazzo daniele.varra...@gmail.com: On Mon, Sep 22, 2014 at 8:17 AM, Dmitriy Igrishin dmit...@gmail.com wrote: 2014-09-22 10:42 GMT+04:00 Daniele Varrazzo daniele.varra...@gmail.com : [2] https://gist.github.com/dvarrazzo/065f343c95f8ea67cf8f Why

Re: [HACKERS] libpq connection status and closed fd

On 9/22/14 9:45 AM, Dmitriy Igrishin wrote: 2014-09-22 11:35 GMT+04:00 Daniele Varrazzo daniele.varra...@gmail.com: On Mon, Sep 22, 2014 at 8:17 AM, Dmitriy Igrishin dmit...@gmail.com wrote: Why are you using close() instead of PQfinish()? Because I'm testing for an error, please read my

Re: [HACKERS] libpq connection status and closed fd

2014-09-22 12:36 GMT+04:00 Marko Tiikkaja ma...@joh.to: On 9/22/14 9:45 AM, Dmitriy Igrishin wrote: 2014-09-22 11:35 GMT+04:00 Daniele Varrazzo daniele.varra...@gmail.com: On Mon, Sep 22, 2014 at 8:17 AM, Dmitriy Igrishin dmit...@gmail.com wrote: Why are you using close() instead of

Re: [HACKERS] libpq connection status and closed fd

On 2014-09-22 07:42:01 +0100, Daniele Varrazzo wrote: Hello, a psycopg user is reporting [1] that the library is not marking the connection as closed and/or bad after certain errors, such as a connection timeout. He is emulating the error by closing the connection fd (I don't know if the

Re: [HACKERS] libpq connection status and closed fd

On 9/22/14 10:57 AM, Andres Freund wrote: On 2014-09-22 07:42:01 +0100, Daniele Varrazzo wrote: Is this intentional? Is there a better way to check for a broken connection? Note that the libpq code treats connection resets differently from other, arbitrary, errors: I.e. if the kernel returns

Re: [HACKERS] libpq connection status and closed fd

Daniele Varrazzo daniele.varra...@gmail.com writes: a psycopg user is reporting [1] that the library is not marking the connection as closed and/or bad after certain errors, such as a connection timeout. He is emulating the error by closing the connection fd That seems like a completely

Re: [HACKERS] libpq: PQexec may block indefinitly

On Mon, May 26, 2014 at 1:34 PM, Dmitry Samonenko shreddingw...@gmail.com wrote: 1. Connection to PSQL server is made without an option to specify SO_RCVTIMEO and SO_SNDTIMEO. Why is that? Is setting socket timeouts considered harmful? 2. PQexec ultimately leads to PQwait, which after some

Re: [HACKERS] libpq: How to get the error code after a failed PGconn connection

Hello World worldani...@gmail.com writes: Given the following code. PGconn* const conn=PQconnectdbParams(keywords, values, false); if(! conn || PQstatus(conn)!=CONNECTION_OK){ /* error code? */ } - In case of a failed connection is there a way to get the error code to be able to distinguish

Re: [HACKERS] libpq thread locking during SSL connection start

On Mon, 2013-08-12 at 10:49 -0400, Stephen Frost wrote: Alternatively, if we want to just print an error message and proceed, we should put the strerror based on the return value into the message. That could certainly be added. Here is a patch for that. I also adjusted the message

Re: [HACKERS] libpq thread locking during SSL connection start

On 8/1/13 1:42 PM, Stephen Frost wrote: * Alvaro Herrera (alvhe...@2ndquadrant.com) wrote: pgsecure_open_client() returns -1 if it can't lock the mutex. This is a problem because the callers are not prepared for that return value. I think it should return PGRES_POLLING_FAILED instead, after

Re: [HACKERS] libpq thread locking during SSL connection start

* Peter Eisentraut (pete...@gmx.net) wrote: On 8/1/13 1:42 PM, Stephen Frost wrote: * Alvaro Herrera (alvhe...@2ndquadrant.com) wrote: pgsecure_open_client() returns -1 if it can't lock the mutex. This is a problem because the callers are not prepared for that return value. I think it

Re: [HACKERS] libpq thread locking during SSL connection start

Stephen Frost wrote: All, I wanted to highlight the below commit as being a significant enough change that it warrents being seen on -hackers and not just -committers. If you use SSL with libpq, particularly in a threaded mode/environment, please take a look/test this change.

Re: [HACKERS] libpq thread locking during SSL connection start

* Alvaro Herrera (alvhe...@2ndquadrant.com) wrote: pgsecure_open_client() returns -1 if it can't lock the mutex. This is a problem because the callers are not prepared for that return value. I think it should return PGRES_POLLING_FAILED instead, after setting an appropriate error message in

Re: [HACKERS] libpq COPY handling

On Thu, Apr 25, 2013 at 1:56 PM, Tom Lane t...@sss.pgh.pa.us wrote: However, the documentation in libpq.sgml is a bit bogus too, because it counsels trying the PQputCopyEnd() call again, which will not work (since we already changed the asyncStatus). We could make that say a zero result is

Re: [HACKERS] libpq COPY handling

Robert Haas robertmh...@gmail.com writes: On Thu, Apr 25, 2013 at 1:56 PM, Tom Lane t...@sss.pgh.pa.us wrote: However, the documentation in libpq.sgml is a bit bogus too, because it counsels trying the PQputCopyEnd() call again, which will not work (since we already changed the asyncStatus).

Re: [HACKERS] libpq COPY handling

On Fri, Apr 26, 2013 at 10:48 AM, Tom Lane t...@sss.pgh.pa.us wrote: Robert Haas robertmh...@gmail.com writes: On Thu, Apr 25, 2013 at 1:56 PM, Tom Lane t...@sss.pgh.pa.us wrote: However, the documentation in libpq.sgml is a bit bogus too, because it counsels trying the PQputCopyEnd() call

Re: [HACKERS] libpq COPY handling

On 27/04/13 02:48, Tom Lane wrote: Robert Haas robertmh...@gmail.com writes: On Thu, Apr 25, 2013 at 1:56 PM, Tom Lane t...@sss.pgh.pa.us wrote: However, the documentation in libpq.sgml is a bit bogus too, because it counsels trying the PQputCopyEnd() call again, which will not work (since we

Re: [HACKERS] libpq COPY handling

Robert Haas robertmh...@gmail.com writes: Noah Misch pointed out something interesting to me: /* * PQputCopyEnd - send EOF indication to the backend during COPY IN * * After calling this, use PQgetResult() to check command completion status. * * Returns 1 if successful, 0 if data could

Re: [HACKERS] LIBPQ Implementation Requiring BYTEA Data

On Sun, Mar 3, 2013 at 9:54 PM, Cliff_Bytes cr...@eclipssolutions.com wrote: Hello All First, I am new to this great forum. I have a challenge on my hand as follows. I am a long time libpq user but have never used the BYTEA data type nor its related functions until now. I have am writing

Re: [HACKERS] LIBPQ Implementation Requiring BYTEA Data

Merlin I will try your suggestion, thanks. I am somewhat surprised to find few hacks related to my issue. And the BYTEA type and function documentation leave much to be desired, IMHO, being a newbie on the Type BYTEA front. -- View this message in context:

Re: [HACKERS] LIBPQ Implementation Requiring BYTEA Data

On 03/04/2013 11:57 PM, Cliff_Bytes wrote: Merlin I will try your suggestion, thanks. I am somewhat surprised to find few hacks related to my issue. And the BYTEA type and function documentation leave much to be desired, IMHO, being a newbie on the Type BYTEA front. One of the most helpful

Re: [HACKERS] LIBPQ Implementation Requiring BYTEA Data

On 03/04/2013 11:54 AM, Cliff_Bytes wrote: Hello All First, I am new to this great forum. I have a challenge on my hand as follows. I am a long time libpq user but have never used the BYTEA data type nor its related functions until now. I have am writing an interface for a web based

Re: [HACKERS] LIBPQ Implementation Requiring BYTEA Data

Thanks for the reply, Craig Fair enough so a little more background, perhaps. I have the core of this program running (command line) successfully with libpq and mcrypt already for some time. My goal now is to house the encrypted file data in a table with all user processing done over the SSL

Re: [HACKERS] LIBPQ Implementation Requiring BYTEA Data

On 03/04/2013 01:51 PM, Cliff_Bytes wrote: I hope this pseudo illustrates more of what I am doing to insert encrypted data into a bytea column and then query the same column for decryption. It does, but it doesn't let anyone compile it and actually reproduce the problem you're encountering or

Re: [HACKERS] LIBPQ Implementation Requiring BYTEA Data

*That was a brilliant response! Thank you.* -- View this message in context: http://postgresql.1045698.n5.nabble.com/LIBPQ-Implementation-Requiring-BYTEA-Data-tp5747243p5747263.html Sent from the PostgreSQL - hackers mailing list archive at Nabble.com. -- Sent via pgsql-hackers mailing

Re: [HACKERS] LIBPQ Implementation Requiring BYTEA Data

On 03/04/2013 11:54 AM, Cliff_Bytes wrote: I have a challenge on my hand as follows. I am a long time libpq user but have never used the BYTEA data type nor its related functions until now. I have am writing an interface for a web based application written in C using libmcrypt and, of

Re: [RFC] ideas for a new Python DBAPI driver (was Re: [HACKERS] libpq test suite)

On Thursday 14 February 2013, Manlio Perillo wrote: Il 14/02/2013 14:06, Albe Laurenz ha scritto: Manlio Perillo wrote: Sorry for the question, but where can I find the libpq test suite? I can not find it in the PostgreSQL sources; it seems that there are only some examples, in

Re: [RFC] ideas for a new Python DBAPI driver (was Re: [HACKERS] libpq test suite)

-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Il 15/02/2013 02:45, Andrew McNamara ha scritto: For my Python DBAPI2 PostgreSQL driver I plan the following optimizations: I suggest you have a look at my Python ocpgdb driver: http://code.google.com/p/ocpgdb/ Thanks, I did not know it.

Re: [RFC] ideas for a new Python DBAPI driver (was Re: [HACKERS] libpq test suite)

On 2/14/13 2:42 PM, Marko Tiikkaja wrote: I think the reason this doesn't work is that in order to prepare a query you need to know the parameter types, but you don't know that in Python, or at least with the way the DB-API works. For example, if you write cur.execute(SELECT * FROM tbl WHERE

Re: [RFC] ideas for a new Python DBAPI driver (was Re: [HACKERS] libpq test suite)

On Fri, Feb 15, 2013 at 9:28 PM, Peter Eisentraut pete...@gmx.net wrote: On 2/14/13 2:42 PM, Marko Tiikkaja wrote: I think the reason this doesn't work is that in order to prepare a query you need to know the parameter types, but you don't know that in Python, or at least with the way the

Re: [HACKERS] libpq test suite

Manlio Perillo wrote: Sorry for the question, but where can I find the libpq test suite? I can not find it in the PostgreSQL sources; it seems that there are only some examples, in src/test/examples. The regression tests are in src/interfaces/libpq/test and currently contain only URL parsing

[RFC] ideas for a new Python DBAPI driver (was Re: [HACKERS] libpq test suite)

-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Il 14/02/2013 14:06, Albe Laurenz ha scritto: Manlio Perillo wrote: Sorry for the question, but where can I find the libpq test suite? I can not find it in the PostgreSQL sources; it seems that there are only some examples, in src/test/examples.

Re: [RFC] ideas for a new Python DBAPI driver (was Re: [HACKERS] libpq test suite)

-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 A number of the described features sound quite useful. Is it not practical to extend an existing library such as psycopg2? What method will you use to call libpq functions? As you are no doubt aware, psycopg2 uses the traditional CPython API but there

Re: [RFC] ideas for a new Python DBAPI driver (was Re: [HACKERS] libpq test suite)

-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Il 14/02/2013 18:18, Jonathan Rogers ha scritto: A number of the described features sound quite useful. Is it not practical to extend an existing library such as psycopg2? I suspect there are compatibility issues. What method will you use to

Re: [RFC] ideas for a new Python DBAPI driver (was Re: [HACKERS] libpq test suite)

On 2/14/13 9:23 AM, Manlio Perillo wrote: 1) always use PQsendQueryParams functions. This will avoid having to escape parameters, as it is done in psycopg2 (IMHO it still use simple query protocol for compatibility purpose) I think the reason this doesn't work is that in order to

Re: [RFC] ideas for a new Python DBAPI driver (was Re: [HACKERS] libpq test suite)

-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Il 14/02/2013 20:01, Peter Eisentraut ha scritto: On 2/14/13 9:23 AM, Manlio Perillo wrote: 1) always use PQsendQueryParams functions. This will avoid having to escape parameters, as it is done in psycopg2 (IMHO it still use simple

Re: [RFC] ideas for a new Python DBAPI driver (was Re: [HACKERS] libpq test suite)

On 14/02/2013 20:01, Peter Eisentraut wrote: On 2/14/13 9:23 AM, Manlio Perillo wrote: 1) always use PQsendQueryParams functions. This will avoid having to escape parameters, as it is done in psycopg2 (IMHO it still use simple query protocol for compatibility purpose) I think the

Re: [RFC] ideas for a new Python DBAPI driver (was Re: [HACKERS] libpq test suite)

For my Python DBAPI2 PostgreSQL driver I plan the following optimizations: I suggest you have a look at my Python ocpgdb driver: http://code.google.com/p/ocpgdb/ It uses the v3 binary protocol exclusively (to avoid the usual escaping security issues). A number of gotchyas were discovered

Re: [HACKERS] libpq

It seems not unusual for Linux distributions to supply libpq as part of a separate package (whether via dpkg, which I think uses ar as the archiver, or RPM, which uses cpio). Possibly this is already provided on your system via some means akin to those. If, instead, you are keen on getting the

Re: [HACKERS] libpq

On Tue, Nov 06, 2012 at 04:04:51PM -0500, Christopher Browne wrote: It seems not unusual for Linux distributions to supply libpq as part of a separate package (whether via dpkg, which I think uses ar as the archiver, or RPM, which uses cpio). Possibly this is already provided on your system

Re: [HACKERS] libpq

Christopher Browne cbbro...@gmail.com writes: It seems not unusual for Linux distributions to supply libpq as part of a archiver, or RPM, which uses cpio). AFAIK, it's standard to ship libpq plus minimum required supporting files in a postgresql-libs or similarly named package. Certainly the

Re: [HACKERS] libpq

On Tue, Nov 6, 2012 at 6:59 PM, Tom Lane t...@sss.pgh.pa.us wrote: If, instead, you are keen on getting the source code for libpq in a separate tarball, I'd seriously question why that would be expected to be valuable. On most systems, these days, it doesn't take terribly much time or space

Re: [HACKERS] libpq

Claudio Freire klaussfre...@gmail.com writes: Maybe anl libs / install-libs makefile target? I've already faced the complicated procedure one has to go through to build and install only libpq built from source. The documentation already suggests gmake -C src/interfaces install Dunno

Re: [HACKERS] libpq

On Tue, Nov 6, 2012 at 7:25 PM, Tom Lane t...@sss.pgh.pa.us wrote: Claudio Freire klaussfre...@gmail.com writes: Maybe anl libs / install-libs makefile target? I've already faced the complicated procedure one has to go through to build and install only libpq built from source. The

Re: [HACKERS] libpq compression

On Sun, Jun 17, 2012 at 11:45:54PM +0800, Magnus Hagander wrote: On Sun, Jun 17, 2012 at 11:42 PM, Tom Lane t...@sss.pgh.pa.us wrote: Magnus Hagander mag...@hagander.net writes: Is there a reason why we don't have a parameter on the client mirroring ssl_ciphers? Dunno, do we need one?  

Re: [HACKERS] libpq compression

On Mon, Jun 25, 2012 at 2:26 PM, Magnus Hagander mag...@hagander.net wrote: On Mon, Jun 25, 2012 at 4:04 AM, Robert Haas robertmh...@gmail.com wrote: On Fri, Jun 22, 2012 at 12:38 PM, Euler Taveira eu...@timbira.com wrote: On 20-06-2012 17:40, Marko Kreen wrote: On Wed, Jun 20, 2012 at 10:05

Re: [HACKERS] libpq URI and regression testing

Excerpts from Alex's message of jue abr 19 17:06:05 -0300 2012: Peter Eisentraut pete...@gmx.net writes: On tor, 2012-04-19 at 00:13 +0300, Alex wrote: +#!/usr/bin/env perl Don't do that. Call the script using $(PERL) from the makefile. Thank you for the suggestion. Attached v2

  1   2   3   4   5   6   7   >