On Tue, Jun 21, 2011 at 3:55 PM, Merlin Moncure mmonc...@gmail.com wrote:
For update, it's a bit more complex - we don't have a replace into
operator...
Actually, we do. 9.1 supports data modifying CTE around which it's
possible to rig a perfectly reasonable upsert...barring that, you
could
On Sun, Jun 19, 2011 at 8:08 PM, Robert Haas robertmh...@gmail.com wrote:
On Sun, Jun 19, 2011 at 11:04 AM, Jeff Shanab jsha...@smartwire.com wrote:
I am wondering If I am missing something obvious. If not, I have a
suggestion for plpgsql.
Stored procedures can accept rows.
Libpq can
On 6/19/2011 11:04 AM, Jeff Shanab wrote:
I am wondering If I am missing something obvious. If not, I have a suggestion
for plpgsql.
Stored procedures can accept rows.
Libpq can receive rows (PQResult).
Wouldn’t it be a great interface if PQResult was “bi-directional”? Create a
result set on
Hey Jeff,
2011/6/19 Jeff Shanab jsha...@smartwire.com
I am wondering If I am missing something obvious. If not, I have a
suggestion for plpgsql.
** **
Stored procedures can accept rows.
Libpq can receive rows (PQResult).
** **
Wouldn’t it be a great interface if PQResult
On Sun, Jun 19, 2011 at 11:04 AM, Jeff Shanab jsha...@smartwire.com wrote:
I am wondering If I am missing something obvious. If not, I have a
suggestion for plpgsql.
Stored procedures can accept rows.
Libpq can receive rows (PQResult).
Wouldn’t it be a great interface if PQResult was
Sébastien Bonnet wrote:
Hi all, and mainly postresql developpers,
I've been reading old posts about the libpq interface related to multi-process
application. The main problem being that after a fork, each process has a DB
connexion, actually the same. If one closes it, the other one
