postgresql/src/test/modules/test_predtest
Tom Lane d8062ead3d Tighten test_predtest's input checks, and improve error messages.
test_predtest() neglected to consider the possibility that
SPI_plan_get_cached_plan would return NULL.  This led to a core
dump if the input (incorrectly) contains more than one SQL
command.

While here, let's expend more than zero effort on the error
message for this case and nearby ones.

Per (half of) bug #18483 from Alexander Kozhemyakin.
Back-patch to all supported branches, not because this is
very significant (it's merely test scaffolding) but to make
our world a bit safer for fuzz testing.

Discussion: https://postgr.es/m/18483-30bfff42de238000@postgresql.org
2024-06-07 16:45:56 -04:00
..
expected Teach optimizer's predtest.c more things about ScalarArrayOpExpr. 2019-03-01 17:14:17 -05:00
sql Teach optimizer's predtest.c more things about ScalarArrayOpExpr. 2019-03-01 17:14:17 -05:00
.gitignore Add test scaffolding for exercising optimizer's predicate-proof logic. 2018-03-08 13:25:26 -05:00
Makefile Split all OBJS style lines in makefiles into one-line-per-entry style. 2019-11-05 14:41:07 -08:00
README Add test scaffolding for exercising optimizer's predicate-proof logic. 2018-03-08 13:25:26 -05:00
test_predtest--1.0.sql Add test scaffolding for exercising optimizer's predicate-proof logic. 2018-03-08 13:25:26 -05:00
test_predtest.c Tighten test_predtest's input checks, and improve error messages. 2024-06-07 16:45:56 -04:00
test_predtest.control Add test scaffolding for exercising optimizer's predicate-proof logic. 2018-03-08 13:25:26 -05:00

test_predtest is a module for checking the correctness of the optimizer's
predicate-proof logic, in src/backend/optimizer/util/predtest.c.

The module provides a function that allows direct application of
predtest.c's exposed functions, predicate_implied_by() and
predicate_refuted_by(), to arbitrary boolean expressions, with direct
inspection of the results.  This could be done indirectly by checking
planner results, but it can be difficult to construct end-to-end test
cases that prove that the expected results were obtained.

In general, the use of this function is like
	select * from test_predtest('query string')
where the query string must be a SELECT returning two boolean
columns, for example

	select * from test_predtest($$
	select x, not x
	from (values (false), (true), (null)) as v(x)
	$$);

The function parses and plans the given query, and then applies the
predtest.c code to the two boolean expressions in the SELECT list, to see
if the first expression can be proven or refuted by the second.  It also
executes the query, and checks the resulting rows to see whether any
claimed implication or refutation relationship actually holds.  If the
query is designed to exercise the expressions on a full set of possible
input values, as in the example above, then this provides a mechanical
cross-check as to whether the proof code has given a correct answer.