Testing concurrent psql

On Wed, May 16, 2007 at 09:43:36AM -0400, Gregory Stark wrote:

I'm looking for corner cases where the concurrent psql patch doesn't
handle things properly. I'm wondering about multiple result sets but
I can't think of any cases where I can test them.

If you submit multiple commands at the psql prompt then psql seems
to stop at the first semicolon and send the query separately. The
only way to send multiple queries together seems to be with -c and I
don't think we have any intention to support asynchronous queries
via that route. Regular queries still work fine via this route.

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?

I don't know about rules, but you can have a SRF return SETOF
REFCURSOR.

Cheers,
David.
--
David Fetter <david@fetter.org> http://fetter.org/
phone: +1 415 235 3778 AIM: dfetter666
Skype: davidfetter

Remember to vote!
Consider donating to PostgreSQL: http://www.postgresql.org/about/donate

On Wed, May 16, 2007 at 09:43:36AM -0400, Gregory Stark wrote:

I'm looking for corner cases where the concurrent psql patch doesn't handle
things properly. I'm wondering about multiple result sets but I can't think of
any cases where I can test them.

If you submit multiple commands at the psql prompt then psql seems to stop at
the first semicolon and send the query separately. The only way to send
multiple queries together seems to be with -c and I don't think we have any
intention to support asynchronous queries via that route. Regular queries
still work fine via this route.

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?
--
Jim Nasby decibel@decibel.org
EnterpriseDB http://enterprisedb.com 512.569.9461 (cell)

"Jim C. Nasby" <decibel@decibel.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. Perhaps it once was allowed and found to cause problems?

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

Greg Stark <gsstark@mit.edu> writes:

"Jim C. Nasby" <decibel@decibel.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.

regression=# create table foo(f1 int);
CREATE TABLE
regression=# create rule r1 as on insert to foo do also
regression-# ( select 1; select 2; select 3 );
CREATE RULE
regression=# insert into foo values(42);
?column?
----------
3
(1 row)

INSERT 0 1
regression=#

This shows BTW that PQexec throws away all but the last select-result;
but they are all delivered to the client.

regards, tom lane

"Tom Lane" <tgl@sss.pgh.pa.us> writes:

Greg Stark <gsstark@mit.edu> writes:

"Jim C. Nasby" <decibel@decibel.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