Nikolay Shaplov wrote: > В письме от 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
Do we really need a dummy index? I was thinking in something that just calls a few C functions to create and parse a string reloption should be more than enough. > > 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... Oh, I didn't mean to steer you away from a C enum. I just meant that we don't need to define the numerical values ourselves -- it should be fine to use whatever the C compiler chooses for each C symbol (enum member name). In the code we don't refer to the values by numerical value, only by the C symbol. -- Álvaro Herrera https://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
