On Thu, Oct 12, 2023 at 3:44 PM Amit Kapila <amit.kapila16@gmail.com> wrote:
>
> 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?
>
OK, I have given those changes as separate patches:
- 0002 (changes the CREATE PUBLICATION parameter ids)
- 0003 (changes CREATE SUBSCRIPTION parameter ids)
> > ~~~
> >
> > 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.
>
As you wish. Done that way in patch 0001.
~~
PSA the v5 patches.
======
Kind Regards,
Peter Smith.
Fujitsu Australia