Re: Testing concurrent psql

From: Gregory Stark <stark(at)enterprisedb(dot)com>
To: "Tom Lane" <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: "Greg Stark" <gsstark(at)mit(dot)edu>, "Jim C(dot) Nasby" <decibel(at)decibel(dot)org>, "PostgreSQL-development" <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Testing concurrent psql
Date: 2007-05-17 02:37:20
Message-ID: 87odkkyy3j.fsf@oxford.xeocode.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

"Tom Lane" <tgl(at)sss(dot)pgh(dot)pa(dot)us> writes:

> Greg Stark <gsstark(at)mit(dot)edu> writes:
>> "Jim C. Nasby" <decibel(at)decibel(dot)org> writes:
>>> On Wed, May 16, 2007 at 09:43:36AM -0400, Gregory Stark wrote:
>>>> I seem to recall there was a way to construct scenarios that returned multiple
>>>> result sets via rules but I don't know how to arrange that. Anyone remember?
>>>
>>> An ALSO SELECT rule?
>
>> It gives you an error.
>
> Not if you do it correctly.

Ah, I was trying to do a ON SELECT DO ALSO SELECT

I now get this using the patched version, I can't see this divergence as a bad
thing though:

postgres=# insert into foo values(42);
?column?
----------
1
(1 row)

?column?
----------
2
(1 row)

?column?
----------
3
(1 row)

INSERT 0 1

It seems to work fine asynchronously too as libpq doesn't report the response
as having been received until all three result sets are there anyways, so it
doesn't require any special handling.

--
Gregory Stark
EnterpriseDB http://www.enterprisedb.com

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Pavan Deolasee 2007-05-17 03:27:26 Re: Lack of urgency in 8.3 reviewing
Previous Message Joshua D. Drake 2007-05-17 01:43:59 Re: Lack of urgency in 8.3 reviewing