Greg,
Not sure whether you're working on this or not?
If so, what do you think of the slightly modified syntax I proposed?
I'm fairly keen on getting this patch completed fairly early on in the
8.4 cycle because it allows a new class of concurrent test case. I think
many people will be happy to
On Tue, 2008-04-08 at 17:10 -0400, Tom Lane wrote:
What seems possibly more useful is to reintroduce \cwait (or hopefully
some better name) and give it the semantics of wait for a response from
any active connection; switch to the first one to respond, printing its
name, and print its result.
On Thu, 2008-04-10 at 05:03 +0930, Shane Ambler wrote:
I do think it is useful for more than typo's in the \join command. What
about a slip where you forget to \g the command. Or you start a query
that seems to be taking too long, background it and look into what is
happening. This would be
Csaba Nagy [EMAIL PROTECTED] writes:
For interactive use in the above mentioned scenario you can use the
'screen' command and start as many psqls as needed
Sure, or you could just start multiple xterms or emacs shell buffers
(my preferred setup).
But I'm sure there are people who would
So, Greg, after all this feedback, are you going to rework the patch?
--
Alvaro Herrerahttp://www.CommandPrompt.com/
The PostgreSQL Company - Command Prompt, Inc.
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your
Alvaro Herrera [EMAIL PROTECTED] writes:
So, Greg, after all this feedback, are you going to rework the patch?
I'm a bit busy now but yes, eventually.
I had in mind that it would probably make sense to start over, stealing code
as appropriate. The main thing is that the logic is a bit twisted
Gregory Stark [EMAIL PROTECTED] writes:
Csaba Nagy [EMAIL PROTECTED] writes:
For interactive use in the above mentioned scenario you can use the
'screen' command and start as many psqls as needed
Sure, or you could just start multiple xterms or emacs shell buffers
(my preferred setup).
Tom Lane [EMAIL PROTECTED] writes:
Alvaro Herrera [EMAIL PROTECTED] writes:
Tom Lane wrote:
It strikes me that with these semantics, \cwait is a lot like a thread
join operation, so we could call it \join or \j.
FWIW on POSIX shell there's something similar called wait.
Tom Lane wrote:
Shane Ambler [EMAIL PROTECTED] writes:
When switching to a conn we also need a non-destructive way out if it is
busy.
Uh, why? Why would you switch to a connection at all, if you didn't
want its result?
What if you switch to the wrong connection and it hasn't finished. Do
Shane Ambler wrote:
Think jobs in a shell, you can suspend a long running process then send
it to the background to work and go on with something else.
So I am thinking something like C-z that will allow you to switch out of
a task that is waiting for results without having to stop it
Alvaro Herrera [EMAIL PROTECTED] writes:
Shane Ambler wrote:
So I am thinking something like C-z that will allow you to switch out of
a task that is waiting for results without having to stop it with C-c.
I agree -- we would need to have a mode on which it is not on any
connection, to
On Apr 9, 2008, at 12:27 PM, Tom Lane wrote:
Alvaro Herrera [EMAIL PROTECTED] writes:
Shane Ambler wrote:
So I am thinking something like C-z that will allow you to switch
out of
a task that is waiting for results without having to stop it with
C-c.
I agree -- we would need to have a
Tom Lane wrote:
Alvaro Herrera [EMAIL PROTECTED] writes:
Shane Ambler wrote:
So I am thinking something like C-z that will allow you to switch out of
a task that is waiting for results without having to stop it with C-c.
I agree -- we would need to have a mode on which it is not on any
[ redirecting to -hackers since -patches isn't the place for general
discussion of feature specifications ]
Gregory Stark [EMAIL PROTECTED] writes:
So based on the feedback and suggestions here this is the interface I suggest:
\connect - to open a new connection keeping the existing one
\g
I wrote:
What seems possibly more useful is to reintroduce \cwait (or hopefully
some better name) and give it the semantics of wait for a response from
any active connection; switch to the first one to respond, printing its
name, and print its result.
It strikes me that with these semantics,
Tom Lane wrote:
I wrote:
What seems possibly more useful is to reintroduce \cwait (or hopefully
some better name) and give it the semantics of wait for a response from
any active connection; switch to the first one to respond, printing its
name, and print its result.
It strikes me that
Alvaro Herrera [EMAIL PROTECTED] writes:
Tom Lane wrote:
It strikes me that with these semantics, \cwait is a lot like a thread
join operation, so we could call it \join or \j.
FWIW on POSIX shell there's something similar called wait.
Tom Lane wrote:
\connect name [ optional connect params ]
\S name
This would require choosing a name for the default session, maybe -.
Or you could use 1 if you figured that people really would prefer
numbers as IDs.
+1 with name as a string, when an empty string is passed a
Tom Lane wrote:
\join connID
Switch to connection connID. If it is busy, wait for
command completion and print the result before offering
a new command prompt.
When switching to a conn we also need a non-destructive way out if it is
busy.
\join (or \join - as
Shane Ambler [EMAIL PROTECTED] writes:
+1 on the \g but I would reverse the syntax -
\g conn1 CERATE INDEX...;
No, not good. If the command requires multiple lines then this creates
an action-at-a-distance behavior. Thought experiment: what would you
expect here:
\g conn1
Shane Ambler [EMAIL PROTECTED] writes:
When switching to a conn we also need a non-destructive way out if it is
busy.
Uh, why? Why would you switch to a connection at all, if you didn't
want its result?
This is a pretty fundamental issue, and insisting that you want that
behavior will make
21 matches
Mail list logo
