On Tue, Jul 14, 2015 at 3:07 PM, Alvaro Herrera <alvhe...@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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
