On Wed, Jul 13, 2022 at 08:14:28AM +, Shinoda, Noriyoshi (PN Japan FSIP)
wrote:
> The attached small patch fixes the message in "createuser --help" command.
> The patch has changed to specify a time stamp for the --valid-for option. I
> don't think the SGML description needs to be modified.
t: Re: Add --{no-,}bypassrls flags to createuser
On Thu, May 26, 2022 at 04:47:46PM +0900, Kyotaro Horiguchi wrote:
> FWIW, the "fancy" here causes me to think about something likely to
> cause syntax breakage of the query to be sent.
>
> createuser -a 'user"1' -a 'user&
On Thu, May 26, 2022 at 04:47:46PM +0900, Kyotaro Horiguchi wrote:
> FWIW, the "fancy" here causes me to think about something likely to
> cause syntax breakage of the query to be sent.
>
> createuser -a 'user"1' -a 'user"2' 'user"3'
> createuser -v "2023-1-1'; DROP TABLE public.x; select '" hoge
On Thu, May 26, 2022 at 02:16:37PM +0900, Shinya Kato wrote:
> On 2022-05-25 11:07, Kyotaro Horiguchi wrote:
>> At Tue, 24 May 2022 10:09:10 -0700, Nathan Bossart
>> wrote in
>> > We're still missing some "fancier" string patterns in the tests, but
>> > we
>> > might just be nitpicking at this
At Thu, 26 May 2022 14:16:37 +0900, Shinya Kato
wrote in
> On 2022-05-25 12:47, Michael Paquier wrote:
> > On Wed, May 25, 2022 at 11:07:52AM +0900, Kyotaro Horiguchi wrote:
> >> I reproduced the same failure at my hand and identified the
> >> cause. Windows' version of getopt_long seems to
On 2022-05-25 12:47, Michael Paquier wrote:
On Wed, May 25, 2022 at 11:07:52AM +0900, Kyotaro Horiguchi wrote:
I reproduced the same failure at my hand and identified the
cause. Windows' version of getopt_long seems to dislike that
non-optional parameters precedes options.
Tweaking the list
On Wed, May 25, 2022 at 11:07:52AM +0900, Kyotaro Horiguchi wrote:
> I reproduced the same failure at my hand and identified the
> cause. Windows' version of getopt_long seems to dislike that
> non-optional parameters precedes options.
Tweaking the list of arguments in some commands kicked by the
At Tue, 24 May 2022 10:09:10 -0700, Nathan Bossart
wrote in
> We're still missing some "fancier" string patterns in the tests, but we
> might just be nitpicking at this point.
Such "fancier" strings should be properly handled by FmtId() and
appendStringLiteralConn. If this is a privilege
On Tue, May 24, 2022 at 08:07:31PM +0900, Shinya Kato wrote:
> On 2022-05-24 11:09, Michael Paquier wrote:
>> On Mon, May 23, 2022 at 09:37:35AM -0700, Nathan Bossart wrote:
>> > Michael also requested a test for multiple -a switches and for fancier
>> > string patterns. Once that is taken care
On 2022-05-24 11:09, Michael Paquier wrote:
On Mon, May 23, 2022 at 09:37:35AM -0700, Nathan Bossart wrote:
Michael also requested a test for multiple -a switches and for fancier
string patterns. Once that is taken care of, I think this can be
marked as
ready-for-committer.
Looking at v7,
On Mon, May 23, 2022 at 09:37:35AM -0700, Nathan Bossart wrote:
> Michael also requested a test for multiple -a switches and for fancier
> string patterns. Once that is taken care of, I think this can be marked as
> ready-for-committer.
Looking at v7, this means to extend the tests to process
On Mon, May 23, 2022 at 11:55:43PM +0900, Shinya Kato wrote:
> On 2022-05-23 16:29, Michael Paquier wrote:
>> May I ask for the addition of tests when one specifies multiple
>> switches for --admin and --member? This would check the code path
>> where you build a list of role names. You could
On 2022-05-23 16:29, Michael Paquier wrote:
+$node->issues_sql_like(
+ [ 'createuser', 'regress_role2', '-a', 'regress_user1' ],
+ qr/statement: CREATE ROLE regress_role2 NOSUPERUSER NOCREATEDB
NOCREATEROLE INHERIT LOGIN ADMIN regress_user1;/,
+ 'add a role as a member with admin option
On Fri, May 20, 2022 at 02:45:19PM -0700, Nathan Bossart wrote:
> Thanks for the new patch! I attached a new version with a few small
> changes. What do you think?
So you have settled down to --member to emulate the clause ROLE.
Well, this choice is fine by me at the end.
>
On 2022-05-21 06:45, Nathan Bossart wrote:
On Thu, May 19, 2022 at 10:35:23AM +0900, Shinya Kato wrote:
I created a new patch to test the new options!
Thanks for the new patch! I attached a new version with a few small
changes. What do you think?
Thanks for updating the patch!
It looks
At Sun, 22 May 2022 09:55:37 +0200, Przemysław Sztoch
wrote in
> David G. Johnston wrote on 5/19/2022 3:46 AM:
> > As an aside, I'd rather overcome this particular objection by having
> > the CREATE object command all accept an optional "COMMENT IS" clause.
> >
> I believe that it is not worth
David G. Johnston wrote on 5/19/2022 3:46 AM:
I think that this feature is at least worth considering - but absent
an existing command that does this I would agree that doing so
constitutes a separate feature.
As an aside, I'd rather overcome this particular objection by having
the CREATE
On Thu, May 19, 2022 at 10:35:23AM +0900, Shinya Kato wrote:
> I created a new patch to test the new options!
Thanks for the new patch! I attached a new version with a few small
changes. What do you think?
--
Nathan Bossart
Amazon Web Services: https://aws.amazon.com
>From
On Wed, May 18, 2022 at 6:35 PM Shinya Kato
wrote:
> > Too bad there's no --comment parameter to do COMMENT ON ROLE name IS
> > 'Comment';
> >
> > As you already make such changes in createuser, I would like to ask
> > for an additional --comment parameter
> > that will allow sysadmins to set a
Thanks for reviews and comments!
On 2022-05-06 07:08, Przemysław Sztoch wrote:
Thanks for the new patch! Would you mind adding some tests for the new
options?
I created a new patch to test the new options!
However, not all option tests exist, so it may be necessary to consider
whether to
Dear Shinya,
Too bad there's no --comment parameter to do COMMENT ON ROLE name IS
'Comment';
As you already make such changes in createuser, I would like to ask for
an additional --comment parameter
that will allow sysadmins to set a comment with additional information
about the new DB
On Thu, Apr 28, 2022 at 03:06:30PM +0900, Shinya Kato wrote:
> On 2022-04-26 05:19, Nathan Bossart wrote:
>> +1 for "member". It might not be perfect, but IMO it's the clearest
>> option.
>
> Thanks! I changed the option "--membership" to "--member".
Thanks for the new patch! Would you mind
Thank you for the reviews!
On 2022-04-26 05:19, Nathan Bossart wrote:
- printf(_(" -g, --role=ROLE new role will be a member of
this role\n"));
+ printf(_(" -g, --role=ROLEnew role will be a member of this
role\n"));
This looks lik an unexpected change.
I fixed it.
On Thu, Apr 21, 2022 at 01:21:57PM -0700, David G. Johnston wrote:
> I'm ok with -m/--member as well (like with --role only one role can be
> specified per switch instance so member, not membership, the later meaning,
> at least for me, the collective).
>
> That -m doesn't match --role-to is no
On Thu, Apr 21, 2022 at 12:51 PM Robert Haas wrote:
> On Thu, Apr 21, 2022 at 12:30 AM Michael Paquier
> wrote:
> > On Tue, Apr 19, 2022 at 12:13:51PM -0400, Robert Haas wrote:
> > > On Mon, Apr 18, 2022 at 9:50 PM Kyotaro Horiguchi
> > > wrote:
> > >> Hmm.. So, "-r/--role" and
On Thu, Apr 21, 2022 at 12:30 AM Michael Paquier wrote:
> On Tue, Apr 19, 2022 at 12:13:51PM -0400, Robert Haas wrote:
> > On Mon, Apr 18, 2022 at 9:50 PM Kyotaro Horiguchi
> > wrote:
> >> Hmm.. So, "-r/--role" and "-m/--member(ship)" is the (least worse) way
> >> to go? Or we can give up
On Tue, Apr 19, 2022 at 12:13:51PM -0400, Robert Haas wrote:
> On Mon, Apr 18, 2022 at 9:50 PM Kyotaro Horiguchi
> wrote:
>> Hmm.. So, "-r/--role" and "-m/--member(ship)" is the (least worse) way
>> to go? Or we can give up adding -m for the reason of being hard to
>> name it..
>
> Hmm, yeah, I
At Tue, 19 Apr 2022 12:13:51 -0400, Robert Haas wrote
in
> On Mon, Apr 18, 2022 at 9:50 PM Kyotaro Horiguchi
> wrote:
> > Hmm.. So, "-r/--role" and "-m/--member(ship)" is the (least worse) way
> > to go? Or we can give up adding -m for the reason of being hard to
> > name it..
>
> Hmm, yeah,
On Mon, Apr 18, 2022 at 9:50 PM Kyotaro Horiguchi
wrote:
> Hmm.. So, "-r/--role" and "-m/--member(ship)" is the (least worse) way
> to go? Or we can give up adding -m for the reason of being hard to
> name it..
Hmm, yeah, I hadn't quite realized what the problem was when I wrote
that. I
Thanks!
At Mon, 18 Apr 2022 09:59:48 -0400, Robert Haas wrote
in
> On Fri, Apr 15, 2022 at 2:33 AM Kyotaro Horiguchi
> wrote:
> > > printf(_(" -b, --belongs-to=ROLE new role will be a member of this
> > > role\n"));
> >
> > + printf(_(" -m, --membership=ROLE this role will be
On Fri, Apr 15, 2022 at 2:33 AM Kyotaro Horiguchi
wrote:
> > printf(_(" -b, --belongs-to=ROLE new role will be a member of this
> > role\n"));
>
> + printf(_(" -m, --membership=ROLE this role will be a member of
> new role\n"));
>
> membership sounds somewhat obscure, it seems
At Fri, 15 Apr 2022 14:55:48 +0900, Shinya Kato
wrote in
> I understand. For backward compatibility, I left the ROLE clause
> option as it is and changed the IN ROLE clause option to --membership
> option.
Thanks!
- printf(_(" -g, --role=ROLE new role will be a member of this
On 2022-04-14 18:57, Daniel Gustafsson wrote:
On 14 Apr 2022, at 09:42, Shinya Kato
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
> On 14 Apr 2022, at 09:42, Shinya Kato 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
On 2022-04-13 17:35, Kyotaro Horiguchi wrote:
At Wed, 13 Apr 2022 16:10:01 +0900, Michael Paquier
wrote in
On Wed, Apr 13, 2022 at 03:46:25PM +0900, Kyotaro Horiguchi wrote:
> It is sensible to rig createuser command with full capability of
> CREATE ROLE is reasonable.
>
> Only --replication
On Wed, Apr 13, 2022 at 4:35 AM Kyotaro Horiguchi
wrote:
> I don't think there's a definitive criteria (other than feasibility)
> for whether each CREATE ROLE option should have the correspondent
> option in the createuser command. I don't see a clear reason why
> createuser command should not
At Wed, 13 Apr 2022 16:10:01 +0900, Michael Paquier wrote
in
> On Wed, Apr 13, 2022 at 03:46:25PM +0900, Kyotaro Horiguchi wrote:
> > It is sensible to rig createuser command with full capability of
> > CREATE ROLE is reasonable.
> >
> > Only --replication is added by commit 9b8aff8c19 (2010)
On Wed, Apr 13, 2022 at 03:46:25PM +0900, Kyotaro Horiguchi wrote:
> It is sensible to rig createuser command with full capability of
> CREATE ROLE is reasonable.
>
> Only --replication is added by commit 9b8aff8c19 (2010) since
> 8ae0d476a9 (2005). BYPASSRLS and NOBYPASSRLS were introduced by
>
At Wed, 13 Apr 2022 14:51:35 +0900, Shinya Kato
wrote in
> Hi,
>
> Add --{no-,}bypassrls flags to createuser.
> The following is an example of execution.
> --
> $ createuser a --bypassrls
> $ psql -c "\du a"
>List of roles
Hi,
Add --{no-,}bypassrls flags to createuser.
The following is an example of execution.
--
$ createuser a --bypassrls
$ psql -c "\du a"
List of roles
Role name | Attributes | Member of
---++---
a | Bypass RLS | {}
--
Do you think
40 matches
Mail list logo
