Re: Aren't lseg_eq and lseg_ne broken?
От | Bruce Momjian |
---|---|
Тема | Re: Aren't lseg_eq and lseg_ne broken? |
Дата | |
Msg-id | 200211291803.gATI3Yn26305@candle.pha.pa.us обсуждение исходный текст |
Ответ на | Aren't lseg_eq and lseg_ne broken? (Tom Lane <tgl@sss.pgh.pa.us>) |
Список | pgsql-hackers |
Tom Lane wrote: > 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)); Yep, there could be no possible reason to double-test something like the original code does. It must be wrong. -- Bruce Momjian | http://candle.pha.pa.us pgman@candle.pha.pa.us | (610) 359-1001+ If your life is a hard drive, | 13 Roberts Road + Christ can be your backup. | Newtown Square, Pennsylvania19073
В списке pgsql-hackers по дате отправления: