Re: best way to test new index?

Yves Weißig<weissig@rbg.informatik.tu-darmstadt.de> wrote:
> Ok, but I thought more like an automated test, or a test which
> checks if the interface is correctly implemented.
I'm not aware of any automated tests which would test whether a new
index type is correctly implemented.  For starters, how would the
test know when the AM should be used, or what correct results would
be?  Perhaps if this was a drop-in replacement for btree you could
cobble something together so that the standard regression tests
(`make check` and such) would use your index type instead of btree,
yielding similar results; but you haven't given us the slightest
clue whether that's the sort of index you're developing.
> what would be the best way to debug in pg? elog? asserts?
If there are clear guidelines on this anywhere, I've missed it or
forgotten it.  Here's what I tend to go by:
(1)  If it's a message which is expected enough to warrant
translation to all the supported languages, use ereport.
(2)  If it's something which should be rare and technical enough not
to warrant burdening the translators, use elog.
(3)  If it's something which "should never happen" unless there is a
programming error within the PostgreSQL code, it should not normally
be checked in production (just development and through beta
testing), and it is sane to panic (effectively restarting
PostgreSQL) when the condition is encountered, use Assert.
That's all independent of what logging level you use.  You may want
to sprinkle your code with elog calls at the DEBUG level during
development, and consider which might be worth keeping at which
debug levels later on.  Sometimes debug calls are conditioned on
#ifdef conditions so that they're not in the executable without a
special build option.
-Kevin