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

Поиск
Список
Период
Сортировка
От Nikolay Shaplov
Тема Re: [PATCH][PROPOSAL] Add enum releation option type
Дата
Msg-id 4468901.Ii3QHyQo2l@x200m
обсуждение исходный текст
Ответ на Re: [PATCH][PROPOSAL] Add enum releation option type  (Aleksandr Parfenov <a.parfenov@postgrespro.ru>)
Ответы Re: [PATCH][PROPOSAL] Add enum releation option type  (Nikolay Shaplov <dhyan@nataraj.su>)
Список pgsql-hackers
В письме от 10 сентября 2018 18:02:10 пользователь Aleksandr Parfenov написал:

> I did a quick look at yout patch and have some questions/points to
> discuss. I like the idea of the patch and think that enum reloptions
> can be useful. Especially for some frequently checked values, as it was
> mentioned before.
Thanks.

> There are few typos in comments, like 'validateing'.
Yeah. Thats my problem. I've rechecked them with spellchecker, and found two
typos. If there are more, please point me to it.

> I have two questions about naming of variables/structures:
>
> 1) variable opt_enum in parse_one_reloption named in different way
> other similar variables named (without underscore).
I've renamed it. If it confuses you, it may confuse others. No reason to
confuse anybody.

>
> 2) enum
> gist_option_buffering_numeric_values/gist_option_buffering_value_numbers.
> Firstly, it has two names.
My mistake. Fixed it.

> Secondly, can we name it gist_option_buffering, why not?
From my point of view, it is not "Gist Buffering Option" itself. It is only a
part of C-code actually that creates "Gist Buffering Option". This enum
defines "Numeric values for Gist Buffering Enum Option". So the logic of the
name is following
(((Gist options)->Buffering)->Numeric Values)

May be "Numeric Values" is not the best name, but this type should be named
gist_option_buffering_[something]. If you have any better idea what this
"something" can be, I will follow your recommendations...

> As you mentioned in previous mail, you prefer to keep enum and
> relopt_enum_element_definition array in the same .h file. I'm not sure,
> but I think it is done to keep everything related to enum in one place
> to avoid inconsistency in case of changes in some part (e.g. change of
> enum without change of array). On the other hand, array content created
> without array creation itself in .h file. Can we move actual array
> creation into same .h file? What is the point to separate array content
> definition and array definition?
Hm... This would be good. We really can do it? ;-) I am not C-expert, some
aspects of C-development is still mysterious for me. So if it is really ok to
create array in .h file, I would be happy to move it there  (This patch does
not include this change, I still want to be sure we can do it)

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

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

Предыдущее
От: Tom Lane
Дата:
Сообщение: Re: [Patch] Create a new session in postmaster by calling setsid()
Следующее
От: Andrew Gierth
Дата:
Сообщение: Re: [Patch] Create a new session in postmaster by calling setsid()