Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1oaRS6-0004G9-2M for pgsql-bugs@arkaria.postgresql.org; Tue, 20 Sep 2022 00:49:30 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.92) (envelope-from ) id 1oaRS3-0005eO-Of for pgsql-bugs@arkaria.postgresql.org; Tue, 20 Sep 2022 00:49:27 +0000 Received: from makus.postgresql.org ([2001:4800:3e1:1::229]) by malur.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1oaQdN-0005CY-A5 for pgsql-bugs@lists.postgresql.org; Mon, 19 Sep 2022 23:57:05 +0000 Received: from sonic305-3.consmr.mail.bf2.yahoo.com ([74.6.133.42]) by makus.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.92) (envelope-from ) id 1oaQdJ-0000i5-Rg for pgsql-bugs@lists.postgresql.org; Mon, 19 Sep 2022 23:57:03 +0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1663631820; bh=3e2f+nzp4uKB8IfJksd7OIXScFuN3bg7BTW8CHS0Klk=; h=Date:From:To:Cc:In-Reply-To:References:Subject:From:Subject:Reply-To; b=MVGMc6ljRHKen79uQ9EuOj4+/NtS1iZMXp3LVZzWeNVL8OBrmF24jA6ufCk+bmmjNxRC9j9esTHwjuxvIgr+vGJiqY1zCDm5oPrzQ64aVHPufXqn9jzKsOqpbrbZH1mVlQU2P9MhTHauuOkZK2ORs61v1dDXqtOUgD3b94jj+eLTDzenIC38Xruez5CcdDcU/1qzC4ElWBeDGYDmHBt5Hj63A6BpfGjDfRLDm3H4XadbGnJ0AG8S7OMr7sD6S/+2lcZigkxpoyVWDeu2gDpcBCeGC8u5Mdq3QJKy4WvO1c3pem4rknZ7ocXyMWsYKfxka9T7z2RAo7UAjvrI/BExSg== X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1663631820; bh=sfG5V/wcsbzRGdMVBgy8zQeipa4511pTxSQZWU2Htcq=; h=X-Sonic-MF:Date:From:To:Subject:From:Subject; b=NWtoF1VGXlm216/c4BmrClF2o7VawUkeAEgFkuyKqbW3yxq6eD430IN8hWMzSuZvmuH/VjN/aZt+TlM46kls1GAoXFYw74WsUmX1J/WHcPIXcmuIHdIhbgaRYLpSzDSgGI3L/wTHOzlcXnLG4J/RoMoWVBf+E7rAAES9OigZLNbM80gZztyBNY0FJLQyYJUJ3mH73FXUh7/eHcfipBQnMdjSAWi2qcrjQebCBz+QrZHnZIvh4C4Q1bkfpFMS7YYwqil6D8HRX/jxIKcp9iZY2A0LwHm44q266SYcgjXOD6B15R37XjyCTcs9VJ8TUogEQPdicqVAdmAbGu49aPzYhw== X-YMail-OSG: SrZNqhkVM1mdOoVZoVBnzjCQPk9y0w7SGE_ppygPVeybYXgozONG4bYi7Gv4u8h slefP1TuLDJ7PiNo4IUBQsphNLjz1UIEDktQ88JCNQQUcjph9ngNp0U3Z9B7YbP7FdqBRCuniKgV 9FzbgrNvxC.ifqIRuLWPFRsTULIvRBc28q0x0GJ9aJ0ltfz6_kYE3Pp56qNM_da7V_YM0UGcD2jW Ft6utZAQzv1wy1fQPiyLO.4Tsvu.rZavGzx.qvLIa843iddT6U9RPSlUduRldU_D4qLXjwlUTLV_ 96c8MIoGWwQbotMJeehb4HHD0UI.jrD_scJz9esg1.BUr_lVWWtORztskaVlGlLiam_nS110GhNx w6JecPDVD_QOqGM3AJR9W13QyRHPYaIQggtC28lx5Suf2bssMEEA.zZ.eWbJrGbN.xlDzJ0TSvjz w.kZlnwvQ8frZvULA5bPAy_Fsj7j7b3D9f_vqyK7PpkeqweOsH5ns1369SlxHNAP5.XYVKxIlox5 BXQ4kwDg4CF7H1gTgau7B4fuKAmsWLcNOfieaChXu2GrZWxW9BEhLshf8s00MVY4tncKTbhjbv4i 2830zyGg9s44es9081cGQWAimzddE.HlUQ33YzXh95Wf9rryEGC3An81Gz6RQaOMyj5boZYB4qE. NP5O0lkOQoDouD7r82GycMzQBKOHiYu6gKYlZ2T9G4Bi4OZZGfRqzKBgatT5DgY6mWu91Q150pPo k1SNYgzQCHQxVygGGFwdSx9Rg0eoNq2L6fOLWCOhrS6Kb2WTa9fco67iWgP3Y5N5FTlmqoahxdnh QZEwKyOxI8eLcS9PCuxDmASjpCvX6wyX2xvHL2o5qZZ3bAyJyuh6suuncZsmWShqrrgSu_aVgNVQ J39M0YmojlexOBr82JO7Eu0JI7zorL7kTkwKGItFGCHMNeC7rtvSvySyDSTUF6PaHo9Is9.o.8cP IeeB.WOndO1V33IhVP9UvwuLt1.SxZ2ZW6b5GY2PHp5a52GHjxCP4b4_vZvkhktRopTGpZthyL9J Yq9ULnXtfRlUzXMRFCS8cUfeNmjtCrNduv12TTy338WoVnuvNtM9uq.suszo6u9_ryENcG.t77BK eRExruHnJETrJuaPXTj3sNlrHC83MLdRNYy0_WZJfL6kIrL9EZuDO7wj12xuFpzkFstQq6765ghL zC3EJGo6tZ7J2A_tjj61hzK1N4yNb8VcLk3cF8BUXTkHDM9u3c2GDPfhqt3weUUjXdwtAVHBwTrL lNoUuaHL0ZY6yhmgKFJ5uIr0Wy3lZ.c7VAgQj4p2KAszDM33BZt07dlR7oDTTNz0Fpj7WSuWIJ1H f3xDEXfmAqg7rVAGBQbjNgbBZGCfengo6CFRXv6fBLGluoxMzoWI9aKRciyondvb5mihHX7xZqs6 NbJOxpq2R0siheoqsY0nrnkgJEAElEcsOsF56x7mlmRON30B0J.dbTC8U9D2fzp_xxCP4bQk2SSY w7RVCBya5jwZymbK9Y4kL5X0ei_O7I3qSVrqfwPUPj2qaVtTYLeTkTj86msdJk7X1xSprRS1mER9 Xei1ZSD0xEOqKl9Pb.FU_Xp0AYQdpFtEpdX7XfEdwQ.fLQSpv95El0suMhHESLhmylgvxALkKCFE LS22iWY_CF6IB80dTgldDbf1Op5U0K4A6TEW6E94DP6JioAZnAjI3BMnGgFR0DwpPsrVaIWKxz8c x0pYsRZQE.V8QDgGa.hIbAEorfvx3CCRK.IiEHXJfrj.88qzLoG4xzpaSlErG5WceHbRWEa7S7Am .lScYLspxRbRUA0lkWRKa8jrHiyRiywIL6d6E7dXW8fO3bWVJJfO1SzP1fNo_oWk42C19fONw4EN 5SI3JjodrM4u3vndJ4J5SJL9uwb8OUvwH1Rs_.uMBDX7rpUz5nv.5kkR_RYmv_6vop_Yqw9ARC7E stDDUTXmiRLzaDcnY9seinNvqNHwBgCsB_2GYxRKqTRd_UlcGBl9CtMeaakma3l_ShfjjY8l5M_6 ETK5PUNiuOVrPgt9Vs97b1QtZzme_ACcykF2dLOCLmG1RiulVDQluCfwZIOXNw7elpM0sNQwJuRI yUHhBy2ACp.sMo22qOX5YqjqPmIALa1z1ttVrBYfNwHl84bf0.kjDsWtiX5mamtfNxEF_lclKOUX DyagTPmcIrYkleQO4AMNpYoIXX3JM_753vvFA0Wi1jD3WX27VvgKyR71k3weQrdj3ZNvHX03dHi2 YXND1rMjoDuRmayzEW9FGSiqmSXXwVQruFT9oXZFEAqDlTCl5dSN2HKrQc0i30d5NZ8A- X-Sonic-MF: Received: from sonic.gate.mail.ne1.yahoo.com by sonic305.consmr.mail.bf2.yahoo.com with HTTP; Mon, 19 Sep 2022 23:57:00 +0000 Date: Mon, 19 Sep 2022 23:56:56 +0000 (UTC) From: eponymous alias To: Tom Lane Cc: pgsql-bugs@lists.postgresql.org Message-ID: <1545842961.29225.1663631816019@mail.yahoo.com> In-Reply-To: <519733.1663618266@sss.pgh.pa.us> References: <2085551791.33703.1663615115771.ref@mail.yahoo.com> <2085551791.33703.1663615115771@mail.yahoo.com> <519733.1663618266@sss.pgh.pa.us> Subject: Re: apparent loss of database access permissions MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_Part_29224_1301209581.1663631816018" X-Mailer: WebService/1.1.20663 YMailNodin Content-Length: 1584 List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk ------=_Part_29224_1301209581.1663631816018 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit > The reason it gets to be like that is that normal grant and revoke > operations don't make any effort to reset the ACL field to null if > the end result of a series of operations chances to be equivalent > to the default. However, for reasons of its own pg_dump has to > compute the set of GRANT/REVOKE commands to issue to get from the > default state to the object's current state --- and in this situation > that list is empty. So no commands are issued, the ACL stays null, ... > > That's not a bug, just an implementation artifact. Okay, thanks for the quick and detailed response. ------=_Part_29224_1301209581.1663631816018 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 7bit
> The reason it gets to be like that is that normal grant and revoke
> operations don't make any effort to reset the ACL field to null if
> the end result of a series of operations chances to be equivalent
> to the default. However, for reasons of its own pg_dump has to
> compute the set of GRANT/REVOKE commands to issue to get from the
> default state to the object's current state --- and in this situation
> that list is empty. So no commands are issued, the ACL stays null, ...
>
> That's not a bug, just an implementation artifact.

Okay, thanks for the quick and detailed response.
------=_Part_29224_1301209581.1663631816018--