Re: BUG #18344: Pruning tables partitioned by bool range fails with invalid strategy
От | Tom Lane |
---|---|
Тема | Re: BUG #18344: Pruning tables partitioned by bool range fails with invalid strategy |
Дата | |
Msg-id | 3263261.1708014503@sss.pgh.pa.us обсуждение исходный текст |
Ответ на | BUG #18344: Pruning tables partitioned by bool range fails with invalid strategy (PG Bug reporting form <noreply@postgresql.org>) |
Ответы |
Re: BUG #18344: Pruning tables partitioned by bool range fails with invalid strategy
Re: BUG #18344: Pruning tables partitioned by bool range fails with invalid strategy |
Список | pgsql-bugs |
PG Bug reporting form <noreply@postgresql.org> writes: > The following query: > CREATE TABLE t (b bool, i int) PARTITION BY RANGE (b, i); > CREATE TABLE tp PARTITION OF t FOR VALUES FROM (false, 0) TO (false, 1); > SELECT * FROM t WHERE b IS NOT true; > fails with ERROR: invalid strategy number 0. > Reproduced on REL_12_STABLE .. master. > The first bad commit for this anomaly is e0693faf7. What seems to be happening is that gen_prune_step_op is getting op_is_ne = true and doing this: /* * For clauses that contain an <> operator, set opstrategy to * InvalidStrategy to signal get_matching_list_bounds to do the right * thing. */ opstep->opstrategy = op_is_ne ? InvalidStrategy : opstrategy; but then we're failing in get_matching_range_bounds, ie somebody taught get_matching_list_bounds to do the right thing but not any of the other code paths. I'm also wondering how we got there in the first place. It looks like match_boolean_partition_clause thinks it can translate "b IS NOT true" to "b <> true", which is flat wrong --- it gives the wrong result for null. regards, tom lane
В списке pgsql-bugs по дате отправления: