On Tue, Jun 21, 2011 at 3:55 PM, Merlin Moncure 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 triviall
On Sun, Jun 19, 2011 at 8:08 PM, Robert Haas wrote:
> On Sun, Jun 19, 2011 at 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).
>>
>> Would
On Sun, Jun 19, 2011 at 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”? C
Hey Jeff,
2011/6/19 Jeff Shanab
> 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-di
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 t
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 the client then call the database with a com
> Uhm... I always thought that sharing the same socket between
> processes is wrong.
Well, I've never thought about it before this problem, but it definitely
appears to me like something not to do. Sharing remote object doesn't sound
right :-(
> My multi-process daemon works like apache with a p
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
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 remains in a
unknown or not stable st
