From: | Christopher Browne <cbbrowne(at)gmail(dot)com> |
---|---|
To: | Amit Kapila <amit(dot)kapila16(at)gmail(dot)com> |
Cc: | Peter Eisentraut <peter_e(at)gmx(dot)net>, Sameer Thakur <samthakur74(at)gmail(dot)com>, PostgreSQL Mailing Lists <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: Extra functionality to createuser |
Date: | 2013-11-19 20:35:51 |
Message-ID: | CAFNqd5V=VVA8w2K2sWXTm+vyaRssPSTVzM=xOez6OT2S6S3Lqw@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Mon, Nov 18, 2013 at 1:01 AM, Amit Kapila <amit(dot)kapila16(at)gmail(dot)com> wrote:
> On Sat, Nov 16, 2013 at 4:57 AM, Christopher Browne <cbbrowne(at)gmail(dot)com> wrote:
> Few comments:
>
> 1.
> + <term><option>-g</></term>
> + <term><option>--roles</></term>
>
> All other options which require argument are of form:
> <term><option>-c <replaceable class="parameter">number</replaceable></></term>
> <term><option>--connection-limit=<replaceable
> class="parameter">number</replaceable></></term>
>
> So I think it is better to have this new option which require argument
> in similar form.
Sounds good, done.
> 2.
> + Indicates roles to associate with this role.
>
> I think word associate is not very clear, wouldn't it be better to
> mention that this new role will be member of roles specified.
> For example:
> Indicates roles to which the new role will be immediately added as a new member.
With a switch of "immediately" and "added", done. That does better
describe the behaviour.
> 3.
> + case 'g':
> + roles = pg_strdup(optarg);
> + break;
>
> If we see most of other options in case handling are ordered as per
> their order in long_options array. For example
>
> static struct option long_options[] = {
> {"host", required_argument, NULL, 'h'},
> {"port", required_argument, NULL, 'p'},
> ..
>
> Now the order of handling for both is same in switch case or while get
> opt_long() function call. I think this makes code easy to understand
> and modify.
> However there is no functionality issue here, so you can keep the code
> as per your existing patch as well, this is just a suggestion.
That is easy enough to change, and yes, indeed, having the new code
look just like what it is near seems an improvement.
I picked the location of the 'g:' in the opt_long() call basically arbitrarily;
if there is any reason for it to go in a different spot, I'd be happy to
shift it.
--
When confronted by a difficult problem, solve it by reducing it to the
question, "How would the Lone Ranger handle this?"
Attachment | Content-Type | Size |
---|---|---|
createuser.diff | text/plain | 2.9 KB |
From | Date | Subject | |
---|---|---|---|
Next Message | Dimitri Fontaine | 2013-11-19 20:42:18 | Re: Suggestion: Issue warning when calling SET TRANSACTION outside transaction block |
Previous Message | Andrew Dunstan | 2013-11-19 20:32:55 | Re: additional json functionality |