Re: Add --{no-,}bypassrls flags to createuser - Mailing list pgsql-hackers

From Shinya Kato
Subject Re: Add --{no-,}bypassrls flags to createuser
Date
Msg-id 850d0579cdad54a37fd777d6b11421ec@oss.nttdata.com
Whole thread Raw
In response to Re: Add --{no-,}bypassrls flags to createuser  (Daniel Gustafsson <daniel@yesql.se>)
Responses Re: Add --{no-,}bypassrls flags to createuser  (Kyotaro Horiguchi <horikyota.ntt@gmail.com>)
List pgsql-hackers
On 2022-04-14 18:57, Daniel Gustafsson wrote:
>> On 14 Apr 2022, at 09:42, Shinya Kato <Shinya11.Kato@oss.nttdata.com> 
>> wrote:
> 
>> To add the ROLE clause, the originally existing --role option 
>> (corresponding to the IN ROLE clause) is changed to the --in-role 
>> option. Would this not be good from a backward compatibility 
>> standpoint?
> 
> -    printf(_("  -g, --role=ROLE           new role will be a member of
> this role\n"));
> +    printf(_("  -g, --in-role=ROLE        new role will be a member of
> this role\n"));
> +    printf(_("  -G, --role=ROLE           this role will be a member of
> new role\n"));
> 
> Won't this make existing scripts to behave differently after an 
> upgrade?  That
> seems like something we should avoid at all costs.

I understand. For backward compatibility, I left the ROLE clause option 
as it is and changed the IN ROLE clause option to --membership option.


-- 
Regards,

--
Shinya Kato
Advanced Computing Technology Center
Research and Development Headquarters
NTT DATA CORPORATION
Attachment

pgsql-hackers by date:

Previous
From: Noah Misch
Date:
Subject: Re: Intermittent buildfarm failures on wrasse
Next
From: Kyotaro Horiguchi
Date:
Subject: Re: Printing backtrace of postgres processes