Aren't lseg_eq and lseg_ne broken?
От | Tom Lane |
---|---|
Тема | Aren't lseg_eq and lseg_ne broken? |
Дата | |
Msg-id | 27545.1038592778@sss.pgh.pa.us обсуждение исходный текст |
Ответы |
Re: Aren't lseg_eq and lseg_ne broken?
|
Список | 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
В списке pgsql-hackers по дате отправления: