Re: Set AUTOCOMMIT to on in script output by pg_dump - Mailing list pgsql-hackers

From Yugo Nagata
Subject Re: Set AUTOCOMMIT to on in script output by pg_dump
Date
Msg-id 20241009151508.eb37141e5ad29d0ca1e44eb9@sraoss.co.jp
Whole thread Raw
In response to Re: Set AUTOCOMMIT to on in script output by pg_dump  ("David G. Johnston" <david.g.johnston@gmail.com>)
List pgsql-hackers
On Tue, 8 Oct 2024 21:37:38 -0700
"David G. Johnston" <david.g.johnston@gmail.com> wrote:

> On Tuesday, October 8, 2024, Tom Lane <tgl@sss.pgh.pa.us> wrote:
> 
> > "David G. Johnston" <david.g.johnston@gmail.com> writes:
> > > On Tuesday, October 8, 2024, Yugo Nagata <nagata@sraoss.co.jp> wrote:
> > >> On Wed, 09 Oct 2024 11:10:37 +0900
> > >> Shinya Kato <Shinya11.Kato@oss.nttdata.com> wrote:
> > >>> When SQL scripts created with pg_dump/pg_dumpall/pg_restore are
> > executed
> > >>> in psql with AUTOCOMMIT turned off, they will not succeed in many
> > cases.
> >
> > > Agreed.  If we aren’t already outputting psql-only stuff I am a strong -1
> > > for making this the first such case.
> >
> > I really doubt that this is the only way in which you can break a
> > pg_dump script by executing it in a non-default psql environment.
> > We'd likely be better advised to spend some documentation effort
> > recommending that pg_dump scripts be executed under "psql --no-psqlrc".
> 
> 
> +1
> 
> Reinforcing that our output script basically assumes a default execution
> environment seems worth mentioning even if it seems self-evident once it’s
> said.

+1

Regards,
Yugo Nagata



-- 
Yugo Nagata <nagata@sraoss.co.jp>



pgsql-hackers by date:

Previous
From: Richard Guo
Date:
Subject: Re: Inconsistent RestrictInfo serial numbers
Next
From: vignesh C
Date:
Subject: Re: Pgoutput not capturing the generated columns