Re: best way to test new index?

Thanks for the answer Kevin!

I am developing an encoded bitmap index, as proposed in
http://citeseerx.ist.psu.edu/viewdoc/summary?doi=10.1.1.44.7570&rank=1

Automated, in my words, would have meant... some SQL-Statements which
create tables, do inserts, deletes, selects and so on and the results
can be compared to a master file or whatsoever. On low level I tend to
go your way and debug with elog, I just thought somebody might have a
different approach on debugging such code.

Yves

Am 22.04.2011 18:30, schrieb Kevin Grittner:
> Yves Weißig<weissig(at)rbg(dot)informatik(dot)tu-darmstadt(dot)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
>