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 1984955.ALf3oO1kU4@x200m
Whole thread Raw
In response to Re: [PATCH][PROPOSAL] Add enum releation option type  (Michael Paquier <michael@paquier.xyz>)
Responses Re: Re: [PATCH][PROPOSAL] Add enum releation option type
List pgsql-hackers
В письме от среда, 20 февраля 2019 г. 15:08:32 MSK пользователь Michael
Paquier написал:

> > 2.5  May be this src/test/modules dummy index is subject to another patch.
> > So I will start working on it right now, but we will do this work not
> > dependent to any other patches. And just add there what we need when it
> > is ready. I would actually add there some code that checks all types of
> > options, because we actually never check that option value from reloptons
> > successfully reaches extension code. I did this checks manually, when I
> > wrote that bigger reloption patch, but there is no facilities to do
> > regularly check is via test suit. Creating dummy index will create such
> > facilities.
>
> bloom is a user-facing extension, while src/test/modules are normally
> not installed (there is an exception for MSVC anyway..), so stressing
> add_enum_reloption in src/test/modules looks more appropriate to me,
> except if you can define an option which is useful for the user and is
> an enum.
I've created a module in src/test/modules where we would be able to add enum
support when that module is commited.

https://commitfest.postgresql.org/23/2064/

I've filed it as a separate patch (it is standalone work as I can feel it).
Sadly I did not manage to prepare it before this commitfest, so I've added it
to a next one. :-((




pgsql-hackers by date:

Previous
From: Peter Eisentraut
Date:
Subject: Re: Row Level Security − leakproof-ness and performance implications
Next
From: Robert Haas
Date:
Subject: Re: Online verification of checksums