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

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