Re: Concurrent psql API

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Shane Ambler <pgsql(at)Sheeky(dot)Biz>
Cc: Gregory Stark <stark(at)enterprisedb(dot)com>, pgsql-hackers(at)postgreSQL(dot)org
Subject: Re: Concurrent psql API
Date: 2008-04-09 03:37:32
Message-ID: 12548.1207712252@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers pgsql-patches

Shane Ambler <pgsql(at)Sheeky(dot)Biz> 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
CREATE INDEX z (<oops, made a mistake>
\r
CREATE INDEX q ...;

And whichever behavior you'd "expect", how would you get the other
one when you needed it? Hidden state sucks.

(Yeah, this argument probably appeals to people who like RPN calculators
more than those who don't...)

psql's established behavior is that \g is issued after the command
it affects, and we should not change that.

regards, tom lane

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Andrew Chernow 2008-04-09 03:38:14 Re: [PATCHES] libpq type system 0.9a
Previous Message Bruce Momjian 2008-04-09 03:12:56 Re: File system snapshots for multiple file systems

Browse pgsql-patches by date

  From Date Subject
Next Message Andrew Chernow 2008-04-09 03:38:14 Re: [PATCHES] libpq type system 0.9a
Previous Message Merlin Moncure 2008-04-09 02:47:17 Re: [PATCHES] libpq type system 0.9a