|From:||Nikolay Shaplov <dhyan(at)nataraj(dot)su>|
|To:||Aleksandr Parfenov <a(dot)parfenov(at)postgrespro(dot)ru>|
|Cc:||Nikita Glukhov <n(dot)gluhov(at)postgrespro(dot)ru>, Alvaro Herrera <alvherre(at)alvh(dot)no-ip(dot)org>, PostgreSQL mailing lists <pgsql-hackers(at)postgresql(dot)org>|
|Subject:||Re: [PATCH][PROPOSAL] Add enum releation option type|
|Views:||Raw Message | Whole Thread | Download mbox | Resend email|
В письме от 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.
> 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
> 2) enum
> 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.
|Next Message||Andrew Gierth||2018-09-12 19:36:22||Re: [Patch] Create a new session in postmaster by calling setsid()|
|Previous Message||Tom Lane||2018-09-12 18:35:05||Re: [Patch] Create a new session in postmaster by calling setsid()|