On 9/5/21, 11:33 PM, "Bossart, Nathan" wrote:
> Attached is an attempt at cleaning the patch up and adding an
> informative comment and a test case.
For future reference, there was another thread for this bug [0], and a
fix was committed [1].
Nathan
[0]
https://postgr.es/m/CAA3qoJnr2%2B1dVJObN
On 9/5/21, 12:14 PM, "Tom Lane" wrote:
> "Bossart, Nathan" writes:
>> Is there a specific style you have in mind for this change, or is your
>> point that the CASE statement should only be reserved for when
>> is_default_acl is true?
>
> I'd be inclined to split this logic out into a separate if-
"Bossart, Nathan" writes:
> On 9/5/21, 10:08 AM, "Tom Lane" wrote:
>> I'm kind of allergic to this SQL coding style, too. It expects the
>> backend to expend many thousands of cycles parsing and then optimizing
>> away a useless CASE, to save a couple of lines of code and a few cycles
>> on the
On 9/5/21, 10:08 AM, "Tom Lane" wrote:
> "Bossart, Nathan" writes:
>> I've attached a quick hack that seems to fix this by adjusting the
>> pg_dump query to use NULL instead of acldefault() for non-global
>> entries. I'm posting this early in order to gather thoughts on the
>> approach and to ma
"Bossart, Nathan" writes:
> The problem appears to be that pg_dump is comparing the entries in
> pg_default_acl to the default ACL (i.e., acldefault()). This is fine
> for "global" entries (i.e., entries with no schema specified), but it
> doesn't work for "non-global" entries (i.e., entries with
The following review has been posted through the commitfest application:
make installcheck-world: tested, passed
Implements feature: tested, passed
Spec compliant: tested, passed
Documentation:not tested
The patch looks fine and successfully fixes the issue of missing
