Re: Set AUTOCOMMIT to on in script output by pg_dump

Thank you all for the comments!

On 2024-10-09 15:15, Yugo Nagata wrote:
> 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

While adding to the documentation is sufficient if users use it 
correctly, users often behave unexpectedly. My intention was to 
implement it in a way that works without issues even if misused. 
However, since the prevailing opinion seems to favor simply updating the 
documentation, I will proceed with that approach.

A new patch is attached.
I am not a native English, so corrections to the texts are welcome.


-- 
Regards,
Shinya Kato
NTT DATA GROUP CORPORATION