On Tue, Jul 26, 2022 at 5:04 AM Peter Smith <smithpb2...@gmail.com> wrote: > > On Mon, Jul 25, 2022 at 7:33 PM vignesh C <vignes...@gmail.com> wrote: > > > > On Mon, Jul 25, 2022 at 12:58 PM Peter Smith <smithpb2...@gmail.com> wrote: > > > > > > Firstly, I have some (case-sensitivity) questions about the previous > > > patch which was already pushed [1]. > > > > > > Q1. create_subscription docs > > > > > > I did not understand why the docs refer to slot_name = NONE, yet the > > > newly added option says origin = none/any. I think that saying origin > > > = NONE/ANY would be more consistent with the existing usage of NONE in > > > this documentation. > > > > Both NONE and none are ok in the case of origin, if you want I can > > change it to NONE/ANY in case of origin to keep it consistent. > > > > I preferred the special origin values should be documented as NONE/ANY > for better consistency, but let's see what others think about it. > > There will also be associated minor changes needed for a few > error/hint messages. >
I am not really sure how much we gain by maintaining consistency with slot_name because if due to this we have to change the error messages as well then it can create an inconsistency with reserved origin names. Consider message: DETAIL: Origin names "any", "none", and names starting with "pg_" are reserved. Now, if we change this to "ANY", "NONE" in the above message, it will look a bit odd as "pg_" starts with lower case letters. -- With Regards, Amit Kapila.
