Re: [PATCH] src/test/modules/dummy_index -- way to test reloptions from inside of access method

From: Dent John <denty(at)QQdd(dot)eu>
To: Nikolay Shaplov <dhyan(at)nataraj(dot)su>
Cc: pgsql-hackers(at)lists(dot)postgresql(dot)org, Michael Paquier <michael(at)paquier(dot)xyz>, Alvaro Herrera <alvherre(at)2ndquadrant(dot)com>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Robert Haas <robertmhaas(at)gmail(dot)com>
Subject: Re: [PATCH] src/test/modules/dummy_index -- way to test reloptions from inside of access method
Date: 2019-06-26 22:17:06
Message-ID: 6EED2D0C-6FC9-4958-BA6C-632E19210531@QQdd.eu
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Hi Nikolay,

> On 3 Apr 2019, at 20:54, Nikolay Shaplov <dhyan(at)nataraj(dot)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 crawling docs, 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. But perhaps 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 difficult to see how you get something clear and concise, while trying to simultaneously serve both INDEX/AM template and reloptions 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/ reloptions are 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 of agree. :-) But I think that argument falls for similar reasons you cite for your initiative — i.e., it’s basically pretty hard to set up the situation where any kind of custom reloption would ever be reported.

Hope that is useful feedback.

denty.

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Tomas Vondra 2019-06-26 22:29:18 Re: mcvstats serialization code is still shy of a load
Previous Message Li, Zheng 2019-06-26 21:26:16 Re: NOT IN subquery optimization