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
|
Список | 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 по дате отправления: