wrong report of unique property in connection#indexes

[vizcay]

The schema reversal of a rails production database started giving problems, all indexes thata were not unique started being reported as unique. But the development db worked fine.. after some research I was able to track the bug to connection#indexes:

1. RDB$INDICES.RDB$UNIQUE holds the interesting property
2. when FB first creates a not unique index, it fills the value with null, and everything works fine (it get's reported as not unique)
3. but for some reason, after a backup-restore cycle, this value gets changed to '0'
4. this has been reported here: [http://tracker.firebirdsql.org/browse/CORE-933;jsessionid=EBB3F797BE85B7CF5A6E6199ED6BB064?actionOrder=desc] but it's not a bug, just an inconsistency: "in system tables null and '0' it's the same".

fb.c line 2904

unique = RTEST(unique) ? Qtrue : Qfalse;
descending = RTEST(descending) ? Qtrue : Qfalse;

So if according to what I've read online RTEST is the same that "if" for ruby, the problem is that 0 is being evaluated to true: it should test for null or 0.

Maybe this is affecting descending also and other system table tests..

Sorry easy fix but I'm not confident touching c ruby

[rowland]

Yes, the fix was easy, but only because you had completed the analysis already. Thanks for the report.