On Mon, Oct 9, 2023 at 12:15 PM Peter Smith <smithpb2...@gmail.com> wrote: > > On Mon, Oct 9, 2023 at 3:32 PM Amit Kapila <amit.kapil...@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.
