Re: Concurrent psql API

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 numerical 
sequence is used as default.

> I'm not real thrilled with overloading \S with two fundamentally
> different behaviors, either.  Can't we find a different string to assign
> to the listing purpose?  Maybe \S without parameter should mean to
> switch to the default session.

I think it seems fine. Fits with \h and \d behaviour.


> Hmm, this still seems a bit notation-heavy, doesn't it?  What if \g&
> takes an arg indicating which connection to issue the command on:
> 
>     \c& conn1
>     \c& conn2
>     ...
>     CREATE INDEX ...  \g& conn1
>     CREATE INDEX ...  \g& conn2
>     ...
>     \cwait
>     \cwait

+1 on the \g& but I would reverse the syntax -

\g& conn1 CERATE INDEX...;

> Not totally sure about that one, but issuing a command on a background
> connection seems appealing for scripting purposes.  It eliminates the
> risk that the query response comes back before you manage to switch away
> from the connection; which would be bad because it would mess up your
> count of how many cwait's you need.  It seems a bit more analogous to
> the use of & in shell scripts, too, where you implicitly fork away from
> the async command.  (Maybe c& shouldn't make the new connection
> foreground either?)

\c& for a new foreground connection
\cb& for a new background connection?




-- 

Shane Ambler
pgSQL (at) Sheeky (dot) Biz

Get Sheeky @ http://Sheeky.Biz