Re: [PATCH][PROPOSAL] Add enum releation option type - Mailing list pgsql-hackers

From Nikolay Shaplov
Subject Re: [PATCH][PROPOSAL] Add enum releation option type
Date
Msg-id 29235994.NprrEGRed4@x200m
Whole thread Raw
In response to Re: [PATCH][PROPOSAL] Add enum releation option type  (Alvaro Herrera <alvherre@alvh.no-ip.org>)
Responses Re: [PATCH][PROPOSAL] Add enum releation option type  (Alvaro Herrera <alvherre@alvh.no-ip.org>)
List pgsql-hackers
В письме от 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

> 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...


--
Do code for fun.
Attachment

pgsql-hackers by date:

Previous
From: Jorge Solórzano
Date:
Subject: Re: Cached/global query plans, autopreparation
Next
From: Alvaro Herrera
Date:
Subject: Re: [PATCH][PROPOSAL] Add enum releation option type