Re: Concurrent psql patch - Mailing list pgsql-patches

From Gregory Stark
Subject Re: Concurrent psql patch
Date
Msg-id 87d51472a9.fsf@oxford.xeocode.com
Whole thread Raw
In response to Re: Concurrent psql patch  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: Concurrent psql patch
Re: Concurrent psql patch
List pgsql-patches
"Tom Lane" <tgl@sss.pgh.pa.us> writes:

> Gregory Stark <stark@enterprisedb.com> writes:
>> "David Fetter" <david@fetter.org> writes:
>>> What's the reasoning behind \c&?  Does it "send things into the
>>> background" the way & does in the shell?
>
>> Sort of. It sends the *subsequent* command to the background...
>
> That sounds just bizarre.  Existing backslash commands that do something
> to a SQL command are typed *after* the command they affect (\g for
> instance).  I don't think you should randomly change that.

So would you prefer \g& as Jim Nasby suggested? I hadn't even considered that
previously since I'm not accustomed to using \g but it does seem kind of
pretty. I normally use ; but I suppose there's nothing wrong with just
declaring that asynchronous commands must be issued using \g& rather than use
the semicolon to fire them off.

--
  Gregory Stark
  EnterpriseDB          http://www.enterprisedb.com


pgsql-patches by date:

Previous
From: Andrew Dunstan
Date:
Subject: Re: [DOCS] OS/X startup scripts
Next
From: Tom Lane
Date:
Subject: Re: Have vacuum emit a warning when it runs out of maintenance_work_mem