Minor refactor: Use more consistent names for the labels of PG_Locale_Strategy
Hi,
When working on the regex code I noticed that the labels of
PG_Locale_Strategy had become inconsistent with the addition of
PG_REGEX_BUILTIN but while at it I also noticed that
PG_REGEX_LOCALE_WIDE_L and PG_REGEX_LOCALE_1BYTE_L did not make it
obvious that they were libc-related so I propose a new naming scheme:
PG_STRATEGY_<type>[_<subtype>]
I am open for other suggestions of course like keeping the PG_LOCALE_*
prefix, but in any case I think we should make the enum labels consistent.
Andreas
Attachments:
0001-Rename-enum-label-names-for-PG_Locale_Strategy.patchtext/x-patch; charset=UTF-8; name=0001-Rename-enum-label-names-for-PG_Locale_Strategy.patchDownload+70-71
On Wed, Aug 28, 2024 at 04:58:16PM +0200, Andreas Karlsson wrote:
When working on the regex code I noticed that the labels of
PG_Locale_Strategy had become inconsistent with the addition of
PG_REGEX_BUILTIN but while at it I also noticed that PG_REGEX_LOCALE_WIDE_L
and PG_REGEX_LOCALE_1BYTE_L did not make it
obvious that they were libc-related so I propose a new naming scheme:PG_STRATEGY_<type>[_<subtype>]
I am open for other suggestions of course like keeping the PG_LOCALE_*
prefix, but in any case I think we should make the enum labels consistent.
+1 for your suggestion, as you are suggesting. The original intention
when PG_Locale_Strategy got introduced was to have everything named as
PG_REGEX_LOCALE_*, but with the built-in part coming in play in this
code adding "STRATEGY" is cleaner than just "LOCALE".
--
MichaelOn Thu, Aug 29, 2024 at 10:06:32AM +0900, Michael Paquier wrote:
+1 for your suggestion, as you are suggesting. The original intention
when PG_Locale_Strategy got introduced was to have everything named as
PG_REGEX_LOCALE_*, but with the built-in part coming in play in this
code adding "STRATEGY" is cleaner than just "LOCALE".
Applied this one as 23138284cde4.
--
Michael