[EMAIL PROTECTED] (D'Arcy J.M. Cain) writes:
>> Obviously it isn't. Care to show us the code?
> Sure. ftp://ftp.vex.net/pub/glaccount.
PG_FUNCTION_INFO_V1(glaccount_cmp);
Datum
glaccount_cmp(PG_FUNCTION_ARGS)
{
glaccount *a1 = (glaccount *) PG_GETARG_POINTER(0);
glaccount *a2 = (glaccount *) PG_GETARG_POINTER(1);
PG_RETURN_BOOL(do_cmp(a1, a2));
}
The btree comparison function needs to return 1/0/-1, not boolean.
Try PG_RETURN_INT32().
PG_FUNCTION_INFO_V1(glaccount_eq);
Datum
glaccount_eq(PG_FUNCTION_ARGS)
{
glaccount *a1 = (glaccount *) PG_GETARG_POINTER(0);
glaccount *a2 = (glaccount *) PG_GETARG_POINTER(1);
PG_RETURN_BOOL (!do_cmp(a1, a2));
}
PG_FUNCTION_INFO_V1(glaccount_ne);
Datum
glaccount_ne(PG_FUNCTION_ARGS)
{
glaccount *a1 = (glaccount *) PG_GETARG_POINTER(0);
glaccount *a2 = (glaccount *) PG_GETARG_POINTER(1);
PG_RETURN_BOOL (!!do_cmp(a1, a2));
}
While these two are not actually wrong, that sort of coding always
makes me itch. Seems like
PG_RETURN_BOOL (do_cmp(a1, a2) == 0);
PG_RETURN_BOOL (do_cmp(a1, a2) != 0);
respectively would be cleaner, more readable, and more like the other
comparison functions. I've always thought that C's lack of distinction
between booleans and integers was a bad design decision; indeed, your
cmp bug kinda proves the point, no?
regards, tom lane
---------------------------(end of broadcast)---------------------------
TIP 3: if posting/reading through Usenet, please send an appropriate
subscribe-nomail command to [EMAIL PROTECTED] so that your
message can get through to the mailing list cleanly
