Content-Type: multipart/alternative;
 boundary="------------95usRktg9ckOjG7gv5Xx9MYg"
Message-ID: <6c540fb7-03d9-4929-8a11-66c2ddccf2b2@dunslane.net>
Date: Thu, 17 Jul 2025 12:09:08 -0400
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: Non-text mode for pg_dumpall
To: =?UTF-8?Q?=C3=81lvaro_Herrera?= <alvherre@alvh.no-ip.org>,
 Mahendra Singh Thalor <mahi6run@gmail.com>
Cc: Noah Misch <noah@leadboat.com>, jian he <jian.universality@gmail.com>,
 Srinath Reddy <srinath2133@gmail.com>, pgsql-hackers@lists.postgresql.org
References: <202507171111.uo3vvgt6jp6j@alvherre.pgsql>
From: Andrew Dunstan <andrew@dunslane.net>
Content-Language: en-US
Autocrypt: addr=andrew@dunslane.net; keydata=
 xsBNBE7KWFkBCAClridxur2AIc7eW2AR7izbfp3EnNefie2HbLF0izW5Ik5UjX2HBXBx4syI
 gY6b0ugohXrr274+baoAlvSbq6cAoQuEVrk5IZFzt20b1Xkx65FwGSEj526yiKLocqkJceSq
 Xr9xcA5SGY+FZv441chh5SU92v4q6z+6LPpoHOh97ptAVXZYNTtU0LevyvD5lja0TzbvJm6C
 eFXitJfnm1pLEr0DGJCR/iUOl/N62Kh4855zZC7NHIjQHPOvV5Stz/l5ilDhvGVk+xkXFPys
 SjZoUr1rXhYLpiyi5sR0X9FHXT0KnGuz1F5ERO7ZTLSSQ6fJwPj6gOk9K+vvoKvoeql5ABEB
 AAHNJEFuZHJldyBEdW5zdGFuIDxhbmRyZXdAZHVuc2xhbmUubmV0PsLAlwQTAQgAQQIbAwIX
 gAIZAQULCQgHAwUVCgkICwUWAgMBAAIeBRYhBOQ+WEYd/Hy/RGkVpZn6f8tZ/DuBBQJoGNGd
 BQkdEO8nAAoJEJn6f8tZ/DuBq74H/jkTR4Zi3stbw+xC7v2u3QozssK7MYPL2AsVfh7OealS
 h182fiWXpfvmmAB7WUHbhk9GC2RAOnHI/2d2jgKaMLAHsGYOT0YopTVIwRY43fCw/mK67yxc
 wmDcX+zyKfLaivNbf5A7QPLNwda98bEAMSJ8Sn652Uc6cA8t3uKGsVzbRBQOoYzjgvBCfSrE
 9ql3PDNg0l4BfAqabd2f70ZUm9VAMEPrgv/v2xI7M2XiL4g5BVmqLCOwxLM8RMCotCuoweUr
 VO43DeBCIDwLxotMJKvGWDjBzQYlU1NPUAtNcz/gN9ITUe1VUGjyvGj4u1lxBOcQQUw7l1+T
 5moZ4iZxXzvOwE0ETspYWQEIANGc4zQULOxhbqO2dyD51YhqCNRmm9oKWaqf+wmW4tpDe/VV
 cxAnNizd4LWCHfzpb5cHAtGkOPePMfzWVf6nvdF7d3eglbtf59+zG7O7llV0xSSoFiieQBsr
 GvqDInXYX/4mRRXMtyhM353/tixC9RWLs1oofyYmCPPXXY7h9R7en3B8BoVrRFcdzlIY/NFN
 hFGW/9dkEiGjgna2Rk6e15kln4ZvFBWUg23p93w/pqXcxY6+k/8TEk+C4R+M6w7o2PLGOjdZ
 +kPiUcw5H85zf/yZJwQXzisXaNduwWB6Vads9YC9dj6kPR1c4VGRqAaYL++LAEOqrlvm2Tvq
 QqZRtnEAEQEAAcLAfAQYAQgAJgIbDBYhBOQ+WEYd/Hy/RGkVpZn6f8tZ/DuBBQJoGNI2BQkd
 EODdAAoJEJn6f8tZ/DuBfw0IAKTsfD40teP/pp+bsLLMSxPXUYrrprTj7WFB5v61p6dkpSr/
 qXmMlyahdxQFaPmfVgVirB1Vk/kHiWNnnGjfUV9nB2Zg9LI0Xb9/ts3LsUiRWXzG3tkMY6XL
 vsVOxW4XFRND9l2q+WW93aZ1DZl+fqWfYgMvsusFRhmGFOKTRfKPta2Pkv+AhA24N4+PrR5p
 bU4k2MO8PAGiK8eaYKGFG1bHKuAvoDoF7WXJ3FHxuWqLnKEt4dfOLm5pAe3zq1Lt6q8azT9i
 QWGpSAK5vQUWQHBHpiDjdPeqKZ6HiAXIIKfSmb+jrvXBqoP+D6/K7rUjG2aXiRtTIAXms9sm
 VRu7cmw=
In-Reply-To: <202507171111.uo3vvgt6jp6j@alvherre.pgsql>
Archived-At: 
 <https://www.postgresql.org/message-id/6c540fb7-03d9-4929-8a11-66c2ddccf2b2%40dunslane.net>
Precedence: bulk

This is a multi-part message in MIME format.
--------------95usRktg9ckOjG7gv5Xx9MYg
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit


On 2025-07-17 Th 7:11 AM, Álvaro Herrera wrote:
> On 2025-Jul-17, Mahendra Singh Thalor wrote:
>
>> To pg_restore, we are giving a dump of pg_dumpall which has a
>> global.dat file and we have drop commands in the global.dat file so
>> when we are using 'globals-only', we are dropping databases as we have
>> DROP commands.
>> As of now, we don't have any filter for global.dat file in restore. If
>> a user wants to restore only globals(without droping db), then they
>> should use 'globals-only' in pg_dumpall.
>> Or if we don't want to DROP databases by global.dat file, then we
>> should add a filter in pg_restore (hard to implement as we have SQL
>> commands in global.dat file).
> I think dropping database is dangerous and makes no practical sense;
> doing it renders pg_dumpall --clean completely unusable.  You're arguing
> from the point of view of ease of implementation, but that doesn't help
> users.


Yeah. I also agree with Noah that we should be consistent with pg_dump. 
And we should err on the side of caution. If we impose a little 
inconvenience on the user by requiring them to drop a database, it's 
better than surprising them by dropping a database when they didn't 
expect it.

There are some subtleties here. pg_restore will only issue DROP DATABASE 
of you use the -C flag, even if you specify --clean, so we need to be 
very careful about issuing DROP DATABASE.

I confess that all this didn't occur to me when working on the commit.

>> I think, for this case, we can do some
>> more doc changes.
>> Example: pg_restore --globals-only : this will restore the global.dat
>> file(including all drop commands). It might drop databases if any drop
>> commands.
> I don't think doc changes are useful.


Yeah, I don't think this is something that can be  cured by documentation.


cheers


andrew

--
Andrew Dunstan
EDB:https://www.enterprisedb.com

--------------95usRktg9ckOjG7gv5Xx9MYg
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: 8bit

<!DOCTYPE html>
<html>
  <head>
    <meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
  </head>
  <body>
    <p><br>
    </p>
    <div class="moz-cite-prefix">On 2025-07-17 Th 7:11 AM, Álvaro
      Herrera wrote:<br>
    </div>
    <blockquote type="cite"
      cite="mid:202507171111.uo3vvgt6jp6j@alvherre.pgsql">
      <pre wrap="" class="moz-quote-pre">On 2025-Jul-17, Mahendra Singh Thalor wrote:

</pre>
      <blockquote type="cite">
        <pre wrap="" class="moz-quote-pre">To pg_restore, we are giving a dump of pg_dumpall which has a
global.dat file and we have drop commands in the global.dat file so
when we are using 'globals-only', we are dropping databases as we have
DROP commands.
As of now, we don't have any filter for global.dat file in restore. If
a user wants to restore only globals(without droping db), then they
should use 'globals-only' in pg_dumpall.
Or if we don't want to DROP databases by global.dat file, then we
should add a filter in pg_restore (hard to implement as we have SQL
commands in global.dat file). 
</pre>
      </blockquote>
      <pre wrap="" class="moz-quote-pre">
I think dropping database is dangerous and makes no practical sense;
doing it renders pg_dumpall --clean completely unusable.  You're arguing
from the point of view of ease of implementation, but that doesn't help
users.</pre>
    </blockquote>
    <p><br>
    </p>
    <p>Yeah. I also agree with Noah that we should be consistent with
      pg_dump. And we should err on the side of caution. If we impose a
      little inconvenience on the user by requiring them to drop a
      database, it's better than surprising them by dropping a database
      when they didn't expect it.</p>
    <p>There are some subtleties here. pg_restore will only issue DROP
      DATABASE of you use the -C flag, even if you specify --clean, so
      we need to be very careful about issuing DROP DATABASE.<br>
    </p>
    <p>I confess that all this didn't occur to me when working on the
      commit.<span style="white-space: pre-wrap"> </span></p>
    <span style="white-space: pre-wrap">
</span>
    <blockquote type="cite"
      cite="mid:202507171111.uo3vvgt6jp6j@alvherre.pgsql">
      <blockquote type="cite">
        <pre wrap="" class="moz-quote-pre">I think, for this case, we can do some
more doc changes.
Example: pg_restore --globals-only : this will restore the global.dat
file(including all drop commands). It might drop databases if any drop
commands.
</pre>
      </blockquote>
      <pre wrap="" class="moz-quote-pre">
I don't think doc changes are useful.</pre>
    </blockquote>
    <p><br>
    </p>
    <p>Yeah, I don't think this is something that can be  cured by
      documentation.</p>
    <p><br>
    </p>
    <p>cheers</p>
    <p><br>
    </p>
    <p>andrew<br>
    </p>
    <pre class="moz-signature"
    signature-switch-id="d0437855-2267-4610-80b3-83167ec45b0b" cols="72">--
Andrew Dunstan
EDB: <a class="moz-txt-link-freetext" href="https://www.enterprisedb.com">https://www.enterprisedb.com</a>
</pre>
  </body>
</html>

--------------95usRktg9ckOjG7gv5Xx9MYg--