Another new regress test
От | Tom Lane |
---|---|
Тема | Another new regress test |
Дата | |
Msg-id | 10968.922588030@sss.pgh.pa.us обсуждение исходный текст |
Ответы |
Re: [HACKERS] Another new regress test
|
Список | pgsql-hackers |
I have added a new regression test "type_sanity" to perform mechanical cross-checks on pg_type, pg_class, and related tables. I also greatly expanded "opr_sanity" to check pg_proc, pg_aggregate, pg_am & friends as well as checking pg_operator more thoroughly. This turned up the usual quota of small errors in the tables, of course ;-) An annoying limitation on these tests is that they can't enforce operand type cross-checks (like whether a pg_operator entry has the same operand and result types as its underlying pg_proc) because of binary-compatible-type cheats that are being done in a few existing cases. For now, I have left those checks out of the regression tests. It would be nice to develop an SQL representation of binary type compatibility so that those checks could be made cleanly. Alternatively, we could make multiple entries in pg_proc for any procedure being used to support multiple types (for example, if int4eq is also used to implement equality of "oid" then it would need to be listed again with oid as the input data type). This would only cost another couple dozen entries in pg_proc, so it might be the best near-term solution. (A very short-term answer would be to turn on the checks anyway, and put the known exception cases into the expected outputs for the tests. That's pretty ugly, not to mention a pain to maintain, but it might be a reasonable thing to do if we aren't going to implement a better solution soon...) regards, tom lane
В списке pgsql-hackers по дате отправления: