On Mon, Oct 9, 2023 at 12:15 PM Peter Smith <smithpb2250@gmail.com> wrote:
>
> On Mon, Oct 9, 2023 at 3:32 PM Amit Kapila <amit.kapila16@gmail.com> wrote:
> >
>
> In v1, I used the same pattern as on the CREATE SUBSCRIPTION page,
> which doesn't look like those...
>
Yeah, I think it would have been better if we used params in the
CREATE SUBSCRIPTION page as well. I don't know if it is a good idea to
do now with this patch but it makes sense to be consistent. What do
you think?
> ~~~
>
> The "Parameters" section describes some things that really are parameters:
>
> e.g.
> "sql-altersubscription-name"
> "sql-altersubscription-new-owner"
> "sql-altersubscription-new-name">
>
> I agree, emphasising that those ones are parameters is better. Changed
> like this in v2.
>
> "sql-altersubscription-params-name"
> "sql-altersubscription-params-new-owner"
> "sql-altersubscription-params-new-name">
>
> ~
>
> But, the "Parameters" section also describes other SQL syntax clauses
> which are not really parameters at all.
>
> e.g.
> "sql-altersubscription-refresh-publication"
> "sql-altersubscription-enable"
> "sql-altersubscription-disable"
>
> So I felt those ones are more intuitive left as they are -- e.g.,
> instead of having ids/linkends like:
>
> "sql-altersubscription-params-refresh-publication"
> "sql-altersubscription-params-enable"
> "sql-altersubscription-params-disable"
>
I checked alter_role.sgml which has similar mixed usage and it is
using 'params' consistently in all cases. So, I would suggest
following a similar style here.
--
With Regards,
Amit Kapila.