On 2018-May-08, Amit Langote wrote:
> I would like to revisit this as a bug fix for get_partition_operator() to
> be applied to both PG 10 and HEAD. In the former case, it fixes the bug
> that constraint exclusion code will fail to prune correctly when partition
> key is of array, enum, range, or record type due to the structural
> mismatch between the OpExpr that partitioning code generates and one that
> the parser generates for WHERE clauses involving partition key columns.
Interesting patchset. Didn't read your previous v2, v3 versions; I only
checked your latest, v1 (???).
I'm wondering about the choice of OIDs in the new test. I wonder if
it's possible to get ANYNONARRAY (or others) by way of having a
polymorphic function that passes its polymorphic argument in a qual. I
suppose it won't do anything in v10, or will it? Worth checking :-)
Why not use IsPolymorphicType? Also, I think it'd be good to have tests
for all these cases (even in v10), just to make sure we don't break it
going forward. At least the array case is clearly broken today ...
A test for the RECORDOID case would be particularly welcome, since it's
somehow different from the other cases. (I didn't understand why did
you remove the test in the latest version.)
--
Álvaro Herrera https://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
