Re: [PATCH][PROPOSAL] Add enum releation option type
От | Nikolay Shaplov |
---|---|
Тема | Re: [PATCH][PROPOSAL] Add enum releation option type |
Дата | |
Msg-id | 15941756.bfKRYTai5T@x200m обсуждение исходный текст |
Ответ на | Re: [PATCH][PROPOSAL] Add enum releation option type (Alvaro Herrera <alvherre@2ndquadrant.com>) |
Ответы |
Re: [PATCH][PROPOSAL] Add enum releation option type
Re: [PATCH][PROPOSAL] Add enum releation option type |
Список | 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 по дате отправления: