New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Use named types in pg_tapgen generated function body tests #34
Use named types in pg_tapgen generated function body tests #34
Conversation
Also reorder the joins and conditions generated for these tests in order to avoid a plan failure if the given function does not exist. Cumulatively, this fixes theory#21.
Is |
Yeah but pgTAP supports 9.1 and later (as of v1.1.0). |
Also improve the implementation of distinct function name selection for functions_are.
The documentation on pgtap.org is still for 1.0 and the pgTAP 1.1 README.md still reflects a minimum PostgreSQL version requirement of 8.4, I think some confusion is forgivable. That said, my experiments suggest that In turn, As no further procedure parameter information functionality has been added to PostgreSQL to date, I think sticking with |
That's fair. I've opened theory/pgtap#262 to clean out the old cruft.
Okay, thanks for digging into that. |
Currently, function body MD5 tests look up the specialization of the function being tested using the raw OIDs of it's arguments. These OIDs are only consistent between databases for built-in types. This means functions using extension types (I.E. hstore) will have differing argument OIDs on different machines, causing tests to fail. Worse, due to the structure of the query the test is not run, meaning only a plan failure results.
This PR corrects both issues in what I believe is a reasonable way for the majority of cases. Unlike the more sophisticated function introspection tools available today,
oidvectortypes
is available on all supported PG versions. And while plan failures will still result if the schema is not present, other direct failures will invariably result from such a situation. As such, I felt keeping the query simple was worth a moderate compromise in function.The duplicate name elimination is just a bonus, the only function change is shorter output. Included as I feel it makes it clearer that this test does not count overloads of the same function name.