Re: Add --{no-,}bypassrls flags to createuser

From: Shinya Kato <Shinya11(dot)Kato(at)oss(dot)nttdata(dot)com>
To: Daniel Gustafsson <daniel(at)yesql(dot)se>
Cc: Kyotaro Horiguchi <horikyota(dot)ntt(at)gmail(dot)com>, Robert Haas <robertmhaas(at)gmail(dot)com>, Michael Paquier <michael(at)paquier(dot)xyz>, PostgreSQL Hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Add --{no-,}bypassrls flags to createuser
Date: 2022-04-15 05:55:48
Message-ID: 850d0579cdad54a37fd777d6b11421ec@oss.nttdata.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On 2022-04-14 18:57, Daniel Gustafsson wrote:
>> On 14 Apr 2022, at 09:42, Shinya Kato <Shinya11(dot)Kato(at)oss(dot)nttdata(dot)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 Content-Type Size
v3-add-bypassrls-flag-to-createuser.patch text/x-diff 9.1 KB

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Kyotaro Horiguchi 2022-04-15 06:19:22 Re: Printing backtrace of postgres processes
Previous Message Noah Misch 2022-04-15 05:21:25 Re: Intermittent buildfarm failures on wrasse