Re: [PATCH][PROPOSAL] Add enum releation option type - Mailing list pgsql-hackers

From Nikolay Shaplov
Subject Re: [PATCH][PROPOSAL] Add enum releation option type
Date
Msg-id 15941756.bfKRYTai5T@x200m
Whole thread Raw
In response to Re: [PATCH][PROPOSAL] Add enum releation option type  (Alvaro Herrera <alvherre@2ndquadrant.com>)
Responses Re: [PATCH][PROPOSAL] Add enum releation option type
Re: [PATCH][PROPOSAL] Add enum releation option type
List pgsql-hackers
В письме от понедельник, 1 июля 2019 г. 14:06:28 MSK пользователь Alvaro
Herrera написал:
> It strikes me that the way to avoid sentence construction is to have
> each enum reloption declare a string that it uses to list the values it
> accepts.  So for example we would have
>
> +#define GIST_OPTION_BUFFERING_ENUM_DEF {   \
> +   { "on",     GIST_OPTION_BUFFERING_ON },     \
> +   { "off",    GIST_OPTION_BUFFERING_OFF },    \
> +   { "auto",   GIST_OPTION_BUFFERING_AUTO },   \
> +   { (const char *) NULL, 0 }                  \
> +}
> +
> + GistBufferingValidMsg = gettext_noop("Valid values are \"on\", \"off\",
> and \"auto\".");
>
> I think that's the most contentious point on this patch at this point
> (though I may be misremembering).

I actually removed "and" from the list and let it be simple coma separated
list

 ERROR:  invalid value for "check_option" option
 DETAIL:  Valid values are: "local", "cascaded".

Now we can translate left part, and subst list to the right part

errdetail("Valid values are: %s.", buf.data)));

It is not that nice as before, but quite acceptable, as I see it.


You do not see it that way?





pgsql-hackers by date:

Previous
From: Nikolay Shaplov
Date:
Subject: Re: [PATCH][PROPOSAL] Add enum releation option type
Next
From: Adrien Nayrat
Date:
Subject: Re: [PATCH] Speedup truncates of relation forks