Re: [HACKERS] Testing concurrent psql
"Tom Lane" <[EMAIL PROTECTED]> writes: > Greg Stark <[EMAIL PROTECTED]> writes: >> "Jim C. Nasby" <[EMAIL PROTECTED]> 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 ---(end of broadcast)--- TIP 4: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] Testing concurrent psql
Greg Stark <[EMAIL PROTECTED]> writes: > "Jim C. Nasby" <[EMAIL PROTECTED]> 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 ---(end of broadcast)--- TIP 9: In versions below 8.0, the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
Re: [HACKERS] Testing concurrent psql
"Jim C. Nasby" <[EMAIL PROTECTED]> 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 ---(end of broadcast)--- TIP 2: Don't 'kill -9' the postmaster
Re: [HACKERS] 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? An ALSO SELECT rule? -- Jim Nasby [EMAIL PROTECTED] EnterpriseDB http://enterprisedb.com 512.569.9461 (cell) ---(end of broadcast)--- TIP 2: Don't 'kill -9' the postmaster
Re: [HACKERS] 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 <[EMAIL PROTECTED]> http://fetter.org/ phone: +1 415 235 3778AIM: dfetter666 Skype: davidfetter Remember to vote! Consider donating to PostgreSQL: http://www.postgresql.org/about/donate ---(end of broadcast)--- TIP 6: explain analyze is your friend
[HACKERS] Testing concurrent psql
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? -- Gregory Stark EnterpriseDB http://www.enterprisedb.com ---(end of broadcast)--- TIP 6: explain analyze is your friend