Hey, this thread was pointed out to me just a few days ago, but I'll start
by saying that I think this thread is on exactly the right track. I don't
like the callback API, and think that PQsetSingleRowMode should be offered
in place of it. But I do have one
On Sat, Jun 16, 2012 at 10:22 AM,
On Mon, Jul 30, 2012 at 9:59 PM, Jan Wieck janwi...@yahoo.com wrote:
On 7/30/2012 8:11 PM, Leon Smith wrote:
One other possibility, Tom Lane fretted ever so slightly about the use
of malloc/free per row... what about instead of PQsetSingleRowMode, you
have PQsetChunkedRowMode that takes
Out of (mostly idle) curiousity, when exactly does a transaction commit,
especially with respect to a TCP connection that a pathological demon will
cut off at the worst possible moment?
The thing is, I'm using PostgreSQL as a queue, using asynchronous
notifications and following the advice of
On Tue, Jun 19, 2012 at 11:59 AM, Robert Haas robertmh...@gmail.com wrote:
On Tue, Jun 19, 2012 at 1:56 AM, Tom Lane t...@sss.pgh.pa.us wrote:
The transaction would be committed before a command success report is
delivered to the client, so I don't think delivered-and-not-marked is
I just realized this is essentially an instance of the Two General's
Problem; which is something I feel should have been more obvious to me.
On Tue, Jun 19, 2012 at 5:50 PM, Leon Smith leon.p.sm...@gmail.com wrote:
On Tue, Jun 19, 2012 at 11:59 AM, Robert Haas robertmh...@gmail.comwrote
A minor issue has come up in creating low-level bindings to libpq for
safe garbage-collected languages, namely that PQfinish is the only
(AFAICT) way to close a connection but also de-allocates the memory
used to represent the database connection.It would be preferable
to call PQfinish to
On Sat, May 14, 2011 at 11:37 AM, Tom Lane t...@sss.pgh.pa.us wrote:
Yes: it'd introduce a new externally-visible state that libpq now has to
worry about supporting in all its operations, ie connection closed but
not gone. This state is guaranteed to be poorly tested and hence buggy.
If you
Hi, I'm the maintainer and a primary author of a postgresql client library
for Haskell, called postgresql-simple, and I recently investigated
improving support for VALUES expressions in this library. As a result, I'd
like to suggest two changes to postgresql:
1. Allow type specifications
On Wed, Feb 26, 2014 at 1:54 PM, Josh Berkus j...@agliodbs.com wrote:
And thank you for writing that driver!
You are welcome!
I have no opinion about your request for VALUES() stuff, though. It
looks fairly complex as far as grammar and libpq is concerned.
Actually, my suggestions
pgmp is also worth mentioning here, and it's likely to be more efficient
than the numeric type or something you hack up yourself:
http://pgmp.projects.pgfoundry.org/
Best,
Leon
On Thu, Apr 10, 2014 at 10:11 AM, k...@rice.edu k...@rice.edu wrote:
On Thu, Apr 10, 2014 at 09:13:47PM +0800,
10 matches
Mail list logo
