Another bug in pg_operator.h
От | Tom Lane |
---|---|
Тема | Another bug in pg_operator.h |
Дата | |
Msg-id | 29556.909607795@sss.pgh.pa.us обсуждение исходный текст |
Ответы |
Re: [HACKERS] Another bug in pg_operator.h
Re: [HACKERS] Another bug in pg_operator.h Re: [HACKERS] Another bug in pg_operator.h |
Список | pgsql-hackers |
As long as we're doing last-minute changes that force initdb ... I believe I've just identified another error in pg_operator.h. Specifically, this tuple is bogus and ought to be deleted: DATA(insert OID = 619 ( "<" PGUID 0 b t f 704 704 16 0 0 0 0 intervalct - - )); This tuple defines "<" on tinterval's (type 704 = TINTERVAL) as being "intervalct", or interval-contained-in. Now that doesn't make a lot of sense. Furthermore there is already a tuple that defines "<<" as being intervalct: DATA(insert OID = 573 ( "<<" PGUID 0 b t f 704 704 16 0 0 0 0 intervalct - - )); and there is another tuple that defines "<" on tintervals as being "intervallt": DATA(insert OID = 813 ( "<" PGUID 0 b t f 704 704 16 813 0 0 0 intervallt - - )); I found this while trying to track down why the tinterval regression test fails on HPUX (it produces the right tuples, but in the wrong sort order ... and unlike the rules case, the select does have an ORDER BY clause). As far as I can tell from the CVS logs, the bogosity has been in there for at least a year. It looks to me like the bogus tuple is masking the correct definition of "<" and causing tintervals to sort incorrectly. Why this doesn't happen on many other machines isn't clear, but maybe it has something to do with the platform-dependency of qsort that we already identified? Anyway, I'm a rank newbie at hacking this stuff, so I'm not about to commit this change without asking someone else to check my work. But if it is indeed wrong, right now seems like a good time to fix it... regards, tom lane
В списке pgsql-hackers по дате отправления: