On Sun, Jan 06, 2019 at 06:28:11PM +0300, Nikolay Shaplov wrote: > Actually I am not satisfied with it too... That is why I started that bigger > reloptions refactoring work. So for now I would offer to keep initialization > as it was for other types: in initialize_reloptions using [type]RelOpts[] > arrays. And then I will offer patch that changes it for all types and remove > difference between biult-in reloptions and reloptions in extensions.
Should this be switched as waiting on author or just marked as returned with feedback then? > 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. -- Michael
signature.asc
Description: PGP signature
