From: | Nikolay Shaplov <dhyan(at)nataraj(dot)su> |
---|---|
To: | pgsql-hackers(at)lists(dot)postgresql(dot)org |
Cc: | Alvaro Herrera <alvherre(at)alvh(dot)no-ip(dot)org>, pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: [PATCH][PROPOSAL] Add enum releation option type |
Date: | 2018-02-15 15:37:20 |
Message-ID: | 29235994.NprrEGRed4@x200m |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | 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.
From | Date | Subject | |
---|---|---|---|
Next Message | Alvaro Herrera | 2018-02-15 15:53:27 | Re: [PATCH][PROPOSAL] Add enum releation option type |
Previous Message | Jorge Solórzano | 2018-02-15 14:31:09 | Re: Cached/global query plans, autopreparation |