From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | pgsql-hackers(at)postgreSQL(dot)org |
Subject: | Aren't lseg_eq and lseg_ne broken? |
Date: | 2002-11-29 17:59:38 |
Message-ID: | 27545.1038592778@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
By chance I just noticed that lseg equality is coded as
Datum
lseg_eq(PG_FUNCTION_ARGS)
{
LSEG *l1 = PG_GETARG_LSEG_P(0);
LSEG *l2 = PG_GETARG_LSEG_P(1);
PG_RETURN_BOOL(FPeq(l1->p[0].x, l2->p[0].x) &&
FPeq(l1->p[1].y, l2->p[1].y) &&
FPeq(l1->p[0].x, l2->p[0].x) &&
FPeq(l1->p[1].y, l2->p[1].y));
}
Surely this should be
PG_RETURN_BOOL(FPeq(l1->p[0].x, l2->p[0].x) &&
FPeq(l1->p[0].y, l2->p[0].y) &&
FPeq(l1->p[1].x, l2->p[1].x) &&
FPeq(l1->p[1].y, l2->p[1].y));
since I don't think I like this result:
regression=# select '[(0, 0), (1, 1)]'::lseg = '[(0, 42), (2, 1)]'::lseg;
?column?
----------
t
(1 row)
lseg_ne has the identical bug.
Checking the CVS archives, I see that this error dates back to the
original Berkeley code, so I'm a bit hesitant to just change it.
Is there any possibility that it really should work this way?
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Bruce Momjian | 2002-11-29 18:03:34 | Re: Aren't lseg_eq and lseg_ne broken? |
Previous Message | Tom Lane | 2002-11-29 17:52:02 | Tightening selection of default sort/group operators |