|From:||Nikolay Shaplov <dhyan(at)nataraj(dot)su>|
|To:||pgsql-hackers(at)postgresql(dot)org, Alvaro Herrera <alvherre(at)2ndquadrant(dot)com>|
|Subject:||[PATCH][PROPOSAL] Add enum releation option type|
|Views:||Raw Message | Whole Thread | Download mbox | Resend email|
While working with my big reloption patch,
I found out, that all relation options of string type in current postgres, are
actually behaving as "enum" type. But each time this behavior is implemented
as validate function plus strcmp to compare option value against one of the
I think it is not the best practice. It is better to have enum type where it
is technically enum, and keep sting type for further usage (for example for
some kind of index patterns or something like this).
Now strcmp in this case does not really slow down postgres, as both string
options are checked when index is created. One check there will not really
slow down. But if in future somebody would want to have such option checked on
regular basis, it is better to have it as enum type: once "strcmp" it while
parsing, and then just "==" when one need to check option value in runtime.
The patch is in attachment. I hope the code is quite clear.
1. I've changed error message from 'Valid values are "XXX", "YYY" and "ZZZ".'
to 'Valid values are "XXX", "YYY", "ZZZ".' to make a code a bit simpler. If it
is not acceptable, please let me know, I will add "and" to the string.
2. Also about the string with the list of acceptable values: the code that
creates this string is inside parse_one_reloption function now. It is a bit
too complex. May be there is already exists some helper function that creates
a string "XXX", "YYY", "ZZZ" from the list of XXX YYY ZZZ values, I do not
know of? Or may be it is reason to create such a function. If so where to
create it? Inside "reloptions.c"? Or it can be reused and I'd better put it
I hope there would be not further difficulties with this patch. Hope it can be
committed in proper time.
Do code for fun.
|Next Message||Nikolay Shaplov||2018-01-21 21:57:22||Re: [HACKERS] [PATCH] Move all am-related reloption code into src/backend/access/[am-name] and get rid of relopt_kind for custom AM|
|Previous Message||Mark Rofail||2018-01-21 21:36:57||Re: [HACKERS] GSoC 2017: Foreign Key Arrays|