Re: [PATCH] src/test/modules/dummy_index -- way to test reloptionsfrom inside of access method
От | Dent John |
---|---|
Тема | Re: [PATCH] src/test/modules/dummy_index -- way to test reloptionsfrom inside of access method |
Дата | |
Msg-id | 6EED2D0C-6FC9-4958-BA6C-632E19210531@QQdd.eu обсуждение исходный текст |
Ответ на | Re: [PATCH] src/test/modules/dummy_index -- way to test reloptions from inside of access method (Nikolay Shaplov <dhyan@nataraj.su>) |
Ответы |
Re: [PATCH] src/test/modules/dummy_index -- way to test reloptionsfrom inside of access method
|
Список | pgsql-hackers |
Hi Nikolay, > On 3 Apr 2019, at 20:54, Nikolay Shaplov <dhyan@nataraj.su> wrote: > > В письме от вторник, 19 марта 2019 г. 16:09:13 MSK пользователь Michael > Paquier написал: > >> Thanks for doing the effort to split that stuff. This looks like an >> interesting base template for anybody willing to look after some >> basics with index AMs, like what's done for FDWs with blackhole_fdw. > I am not sure it is good template. Most methods are empty, and does not show > any example of how it should work. I think it would probably not be a good template — not for a a solid start point. There is value in having something that has all the relevant method signatures, just to save someone the bother of crawlingdocs, or scraping other contrib/ examples for copy/paste snippets. But I think it should really be a different thing.It would be a distraction to litter such a template with custom reloptions clutter. I guess that assumes it is possible to create a realistic AM without configurable options. I’m guessing it should be. Butperhaps such situations are rarer than I imagine…? Better than an empty template, though, would be a concrete, but minimal, implementation of an INDEX/AM. I find it difficultto see how you get something clear and concise, while trying to simultaneously serve both INDEX/AM template andreloptions testing needs. >> Please note that these >> are visible directly via pg_class.reloptions. So we could shave quite >> some code. > Values from pg_class are well tested in regression test. My point here is to > check that they reach index internal as expected. And there is a long way > between pg_class.reloptions and index internals. I had the same thought. But on quick inspection — and perhaps I have missed something — I don’t see that /custom/ reloptionsare really tested at all by the regression tests. So I do think verifying an extension’s custom reloptions exposure would be valuable. I guess you might argue that it’s the regression test suite that should properly test that exposure mechanism. I kind ofagree. :-) But I think that argument falls for similar reasons you cite for your initiative — i.e., it’s basically prettyhard to set up the situation where any kind of custom reloption would ever be reported. Hope that is useful feedback. denty.
В списке pgsql-hackers по дате отправления: