Re: [PATCH][PROPOSAL] Add enum releation option type

Поиск
Список
Период
Сортировка
От Nikolay Shaplov
Тема Re: [PATCH][PROPOSAL] Add enum releation option type
Дата
Msg-id 29235994.NprrEGRed4@x200m
обсуждение исходный текст
Ответ на Re: [PATCH][PROPOSAL] Add enum releation option type  (Alvaro Herrera <alvherre@alvh.no-ip.org>)
Ответы Re: [PATCH][PROPOSAL] Add enum releation option type
Список pgsql-hackers
В письме от 9 февраля 2018 18:45:29 пользователь Alvaro Herrera написал:

> Maybe we need some in-core user to verify the string case still works.
> A new module in src/test/modules perhaps?
I've looked attentively in src/test/modules... To properly test all reloptions
hooks for modules wee need to create an extension with some dummy index in it.
This way we can properly test everything. Creating dummy index would be fun,
but it a quite big deal to create it, so it will require a separate patch to
deal with. So I suppose string reloptions is better to leave untested for now,
with a notion, that it should be done sooner or later

> I don't much like the way you've represented the list of possible values
> for each enum.  I think it'd be better to have a struct that represents
> everything about each value (string name and C symbol.  Maybe the
> numerical value too if that's needed, but is it?  I suppose all code
> should use the C symbol only, so why do we care about the numerical
> value?).
One more reason to keep numeric value, that came to my mind, is that it seems
to be logical to keep enum value in postgres internals represented as C-enum.
And C-enum is actually an int value (can be easily casted both ways). It is
not strictly necessary, but it seems to be a bit logical...


--
Do code for fun.
Вложения

В списке pgsql-hackers по дате отправления:

Предыдущее
От: Jorge Solórzano
Дата:
Сообщение: Re: Cached/global query plans, autopreparation
Следующее
От: Alvaro Herrera
Дата:
Сообщение: Re: [PATCH][PROPOSAL] Add enum releation option type