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 wrote:
> On Thu, Apr 10, 2014 at 09:13:47PM +0800, Olivier Lalonde
On Wed, Feb 26, 2014 at 1:54 PM, Josh Berkus 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 wouldn't necessarily
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 ins
On Mon, Jul 30, 2012 at 9:59 PM, Jan Wieck 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 PQsetChunkedRowMod
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, M
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 wrote:
> On Tue, Jun 19, 2012 at 11:59 AM, Robert Haas wrote:
>
>> On Tue, Jun 19, 2012 at
On Tue, Jun 19, 2012 at 11:59 AM, Robert Haas wrote:
> On Tue, Jun 19, 2012 at 1:56 AM, Tom Lane 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
> > possible.
>
> ...unless you have configu
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 M
On Sat, May 14, 2011 at 11:37 AM, Tom Lane 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 connect to a data
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 free
10 matches
Mail list logo
