On Tue, Jul 14, 2015 at 3:07 PM, Alvaro Herrera
<alvherre@2ndquadrant.com> wrote:
>> We don't have anything that currently tests the Custom Scan interface
>> in the tree. The question is how important that is, and whether it's
>> worth having what's basically a toy implementation just to demonstrate
>> that the feature can work. If so, I think ctidscan is as good a toy
>> example as any; in the interest of full disclosure, I was the one who
>> suggested it in the first place. But I am not entirely sure it's a
>> good idea to saddle ourselves with that maintenance effort. It would
>> be a lot more interesting if we had an example that figured to be
>> generally useful.
>
> As a general principle, I think it's a good idea to have a module that's
> mostly just a skeleton that guides people into writing something real to
> use whatever API is being tested. It needs to be simple enough that not
> much need to be deleted when writing the real thing, and complex enough
> to cover the parts that need covering. If whatever replaces ctidscan is
> too complex, it will not serve that purpose.
>
> My guess is that something whose only purpose is to test the custom scan
> interface for coverage purposes can be simpler than this module.
See, I actually think the opposite: I think we've been accumulating a
reasonable amount of test code that actually serves no really useful
purpose and is just cruft. Stuff like test_shm_mq and test_decoding
seem like they actually catches bugs, so I like that, but I think
stuff like worker_spi is actually TOO simple to be useful in building
anything real, and it provides no useful test coverage, either. But
this is all a matter of opinion, of course, and I'll defer to whatever
the consensus is.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company