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 res
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
"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 twi
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 subscr
"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
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 woul
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
c
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 mo
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
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 i
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
"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".
>
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 mak
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
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 p
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 passe
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".
> http://www.opengroup.org/onlinepubs/009695399/
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 str
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 semant
[ 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
21 matches
Mail list logo
