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 so. That is controlle
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 a
> restart in order
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.
https://www.postgresql.org/docs/10/static/runtime
Hi all,
According to the docs at
https://www.postgresql.org/docs/9.5/static/libpq-connect.html#LIBPQ-CONNSTRING
there are various parameters that control ssl from the client side, including
providing the ssl certs, keys, etc.
Is there a parameter or mechanism for setting the required ssl ciphe
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 3.0, the server responds with
> a Server
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 be able to differentiate
version negotiation (Re: [HACKERS] Libpq PGRES_COPY_BOTH
- version compatibility)
> 1. The client sends a StartupMessage 3.x for version 3.x. We could bump the
> version explicitly, or perhaps we should just coin a version of libpq for
> every server release; e.g. whatever PostgreSQL 11
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
> getting at here. I agree w
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 message. That'll only happen w
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 ServerProtocolVersion (or ParameterStatus) message that
>>> server had i
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 ignored those options and could respond as it saw f
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 the correct text
encodin
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, though.
- Startup["Prot
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 sending some new message (let's say,
>> Negotiat
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 highest protocol version
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 the
>> place to start
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 [/usr/local/pgsql/lib/libpq.so.5.1
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 fo
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 interesting to see how things change if
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.
Traces
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...
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 access the result set row by row
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 column using PQgetvalue. Think of
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 PQgetvalue
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 PQgetvalue. Think of an ORM that is just going to c
On 14 January 2015 at 08:40, Andres Freund 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.
>
All that consumers
On 2015-01-14 08:32:19 -0500, Robert Haas wrote:
> On Fri, Jan 9, 2015 at 2:57 PM, Daurnimator 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 c
On Fri, Jan 9, 2015 at 2:57 PM, Daurnimator 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:
> https://github.com/daurnimator/cqueues
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. Thank
Christoph Berg 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
>> o
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 PQcon
Christoph Berg 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
>> o
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. T
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
fami
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 reve
Bruce Momjian 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 failure, whe
On Fri, Jan 9, 2015 at 06:57:02PM -0500, Tom Lane wrote:
> I wrote:
> > Christoph Berg 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.
On Fri, Jan 9, 2015 at 06:42:19PM -0500, Tom Lane wrote:
> Christoph Berg 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 de
I wrote:
> Christoph Berg 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 P
Christoph Berg 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 code.
It's pos
Hi,
I've got several reports that postfix's pgsql lookup tables are broken
with 9.4's libpq5, while 9.3's libpq5 works just fine. The error
message looks like this:
Jan 10 00:11:40 lehmann postfix/trivial-rewrite[29960]: warning: connect to
pgsql server localhost:5432: out of memory?
Jan 10 00:1
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:
https://github.com/daurnimator/cqueues-pgsql/blob/ee9c3fc85c94669b8128386d99d730fe93d9dbad/cqueues-p
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
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 PQisBusy
>
> > 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
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 exp
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 PQgetQueryCo
On Thursday, December 04, 2014 04:30:27 PM Claudio Freire wrote:
> On Thu, Dec 4, 2014 at 4: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 f
On Thu, Dec 4, 2014 at 4: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, a
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 sugges
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 co
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 applicati
Hi,
The recent discussion about pipelining in the jodbc driver prompted me to look
at what it would take for libpq.
I have a proof of concept patch working. The results are even more promising
than I expected.
While it's true that many applications and frameworks won't easily benefit, it
am
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 definiti
On 2014-09-30 13:42:11 -0700, Peter Geoghegan wrote:
> On Tue, Sep 30, 2014 at 12:57 PM, Christoph Berg 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: 375d8526f29
On Tue, Sep 30, 2014 at 12:57 PM, Christoph Berg 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 should be renamed
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 as it's only present in 9.4+. It's only
used in one file, x
Daniele Varrazzo 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 illegitimate test procedure.
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
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 t
2014-09-22 12:36 GMT+04:00 Marko Tiikkaja :
> On 9/22/14 9:45 AM, Dmitriy Igrishin wrote:
>
>> 2014-09-22 11:35 GMT+04:00 Daniele Varrazzo :
>>
>> On Mon, Sep 22, 2014 at 8:17 AM, Dmitriy Igrishin
>>> wrote:
>>>
Why are you using close() instead of PQfinish()?
>>>
>>> Because I'm testi
On 9/22/14 9:45 AM, Dmitriy Igrishin wrote:
2014-09-22 11:35 GMT+04:00 Daniele Varrazzo :
On Mon, Sep 22, 2014 at 8:17 AM, Dmitriy Igrishin
wrote:
Why are you using close() instead of PQfinish()?
Because I'm testing for an error, please read my message and the
original bug report.
I read
2014-09-22 11:35 GMT+04:00 Daniele Varrazzo :
> On Mon, Sep 22, 2014 at 8:17 AM, Dmitriy Igrishin
> wrote:
> >
> > 2014-09-22 10:42 GMT+04:00 Daniele Varrazzo >:
>
> >> [2] https://gist.github.com/dvarrazzo/065f343c95f8ea67cf8f
> >
> > Why are you using close() instead of PQfinish()?
>
> Because
On Mon, Sep 22, 2014 at 8:17 AM, Dmitriy Igrishin wrote:
>
> 2014-09-22 10:42 GMT+04:00 Daniele Varrazzo :
>> [2] https://gist.github.com/dvarrazzo/065f343c95f8ea67cf8f
>
> Why are you using close() instead of PQfinish()?
Because I'm testing for an error, please read my message and the
original
2014-09-22 10:42 GMT+04:00 Daniele Varrazzo :
> 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 two c
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 two conditions result in the same
effect, but I'll stick to thi
On Mon, May 26, 2014 at 1:34 PM, Dmitry Samonenko
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 function calls
"lands" in p
Greetings.
I have an application which uses libpq for interaction with remote
PostgreSQL server 9.2. Clients and Server nodes are running Linux and
connection is established using TCPv4. The client application has some
small fault-tolerance features, which are activated when server related
problem
Hello World 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 between a (e.g.)
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 between a (e.g.) bad password and the server be
Hi all
While working on something else I just noticed that there's no PQconnect
variant that can consume the output from PQconninfoParse(...), i.e. an
array of PQconninfoOption* .
This would be a nice-to-have for times when you want to pass a connstr,
modify it, and then connect with the modified
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
* 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
> >>
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,
* 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
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.
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. Prior to the
patch, we would c
On 27/04/13 02:48, Tom Lane wrote:
Robert Haas writes:
On Thu, Apr 25, 2013 at 1:56 PM, Tom Lane 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 co
On Fri, Apr 26, 2013 at 10:48 AM, Tom Lane wrote:
> Robert Haas writes:
>> On Thu, Apr 25, 2013 at 1:56 PM, Tom Lane 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 cha
Robert Haas writes:
> On Thu, Apr 25, 2013 at 1:56 PM, Tom Lane 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
On Thu, Apr 25, 2013 at 1:56 PM, Tom Lane 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 informational, y
Robert Haas 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 not be sent (o
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 not be sent (only possible
* in nonblock mode),
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 he
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:
http://postgresql.1045698.n5.nabb
On Sun, Mar 3, 2013 at 9:54 PM, 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
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 cou
*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 list
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 t
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 int
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
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 application written in C using
libmcrypt and, of cours
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
On Fri, Feb 15, 2013 at 9:28 PM, Peter Eisentraut 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 DB-API wor
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
-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 kn
>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 al
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
-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 s
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
1 - 100 of 811 matches
Mail list logo
