Remove hardcoded hash opclass function signature exceptions
От | Peter Eisentraut |
---|---|
Тема | Remove hardcoded hash opclass function signature exceptions |
Дата | |
Msg-id | 29c3b746-69e7-482a-b37c-dbbf7e5b009b@eisentraut.org обсуждение исходный текст |
Ответы |
Re: Remove hardcoded hash opclass function signature exceptions
|
Список | pgsql-hackers |
hashvalidate(), which validates the signatures of support functions for the hash AM, contains several hardcoded exceptions. For example, hash/date_ops support function 1 is hashint4(), which would ordinarily fail validation because the function argument is int4, not date. But this works internally because int4 and date are of the same size. There are several more exceptions like this that happen to work and were allowed historically but would now fail the function signature validation. AFAICT, these exceptions were just carried over from before the current index AM API and validation functions were added. The code contains comments like "For the moment, fix it by having a list of allowed cases.", so it probably wasn't meant as the ideal state. This patch removes those exceptions by providing new support functions that have the proper declared signatures. They internally share most of the C code with the "wrong" functions they replace, so the behavior is still the same. With the exceptions gone, hashvalidate() is now simplified and relies fully on check_amproc_signature(), similar to other index AMs. I'm also fixing one case where a brin opclass used hashvarlena() for bytea, even though in that case, there is no function signature validation done, so it doesn't matter that much. Not done here, but maybe hashvarlena() and hashvarlenaextended() should be removed from pg_proc.dat, since their use as opclass support functions is now dubious. They could continue to exist in the C code as internal support functions.
Вложения
В списке pgsql-hackers по дате отправления: