Re: feature request: auto savepoint for interactive psql when in transaction.

Поиск
Список
Период
Сортировка
От Ross Reedstrom
Тема Re: feature request: auto savepoint for interactive psql when in transaction.
Дата
Msg-id 20120817200807.GB418@rice.edu
обсуждение исходный текст
Ответ на Re: feature request: auto savepoint for interactive psql when in transaction.  (Bruce Momjian <bruce@momjian.us>)
Список pgsql-hackers
On Wed, Aug 15, 2012 at 10:26:55PM -0400, Bruce Momjian wrote:
> On Mon, Nov 14, 2011 at 04:19:30PM -0600, Ross Reedstrom wrote:
> > On Wed, Sep 28, 2011 at 11:47:51AM -0700, David Fetter wrote:
> > > On Wed, Sep 28, 2011 at 02:25:44PM -0400, Gurjeet Singh wrote:
> > > > On Wed, Sep 28, 2011 at 1:51 PM, Kevin Grittner <Kevin.Grittner@wicourts.gov
> > > > > wrote:
> > > > 
> > > > > Alvaro Herrera <alvherre@commandprompt.com> wrote:
> > > > >
> > > > > > See ON_ERROR_ROLLBACK
> > > > > > http://www.postgresql.org/docs/9.0/static/app-psql.html
> > > > >
> > > > > I had missed that.  Dang, this database product is rich with nice
> > > > > features!  :-)
> > > > >
> > > > 
> > > > +1
> > > > 
> > > > I would like it to be on/interactive by default, though.
> > > 
> > > You can have it by putting it in your .psqlrc.
> > > 
> > > If we were just starting out, I'd be all for changing the defaults,
> > > but we're not.  We'd break things unnecessarily if we changed this
> > > default.
> > > 
> > 
> > This discussion died out with a plea for better documentation, and perhaps some
> > form of discoverability. I've scanned ahead and see no further discussion.
> > However, I'm wondering, what use-cases would be broken by setting the default
> > to 'interactive'? Running a non-interactive script by piping it to psql?
> > Reading the code, I see that case is covered: the definition of 'interactive'
> > includes both stdin and stdout are a tty, and the source of commands is stdin.
> > Seems this functionality appeared in version 8.1.  Was there discussion re:
> > making it the default at that time?  I'm all for backward compatibility, but I'm
> > having trouble seeing what would break.
> > 
> > I see that Peter blogged about this from a different angle over a year ago
> > (http://petereisentraut.blogspot.com/2010/03/running-sql-scripts-with-psql.html)
> > which drew a comment from Tom Lane that perhaps we need a better/different tool
> > for running scripts. That would argue the defaults for psql proper should favor
> > safe interactive use (autocommit off, anyone?) Peter mentioned the traditional
> > method unix shells use to handle this: different config files are read for
> > interactive vs. non-interactive startup. Seems we have that, just for the one
> > setting ON_ERROR_ROLLBACK.
> 
> What documentation improvement are you suggesting?  The docs seem clear
> to me.

Wow, that's a blast from the past: November. I think I wasn't looking for docs
changes, just suggested that the thread ended with a plea from others for docs.
I was wondering what supposed breakage would occur by changing the default psql
ON_ERROR_ROLLBACK behavior to 'interactive', since the code guards that pretty
hard to make sure it's a human in a terminal, not a redirect or script.

Ross
-- 
Ross Reedstrom, Ph.D.                                 reedstrm@rice.edu
Systems Engineer & Admin, Research Scientist        phone: 713-348-6166
Connexions                  http://cnx.org            fax: 713-348-3665
Rice University MS-375, Houston, TX 77005
GPG Key fingerprint = F023 82C8 9B0E 2CC6 0D8E  F888 D3AE 810E 88F0 BEDE


> 
> -- 
>   Bruce Momjian  <bruce@momjian.us>        http://momjian.us
>   EnterpriseDB                             http://enterprisedb.com
> 
>   + It's impossible for everything to be true. +
> 
> 
> -- 
> Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
> To make changes to your subscription:
> http://www.postgresql.org/mailpref/pgsql-hackers
> 



В списке pgsql-hackers по дате отправления:

Предыдущее
От: Robert Haas
Дата:
Сообщение: Re: ALTER TABLE lock strength reduction patch is unsafe
Следующее
От: Alvaro Herrera
Дата:
Сообщение: Re: NOT NULL constraints in foreign tables