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