On 12/12/14, 7:16 PM, Tom Lane wrote:
Jim Nasby <jim.na...@bluetreble.com> writes:
I'd say that array_eq (and probably _cmp) just needs to be taught to fall back
to what oper() does, but this part of the commit message gives me pause:
"Change the operator search algorithms to look for appropriate btree or hash index
opclasses, instead of assuming operators named '<' or '=' have the right semantics."
As it should. array_cmp is the basis for a btree opclass, therefore
it must *not* use operators that are not themselves btree operators.
Quite aside from that, we need to move even further away from having
internal system operations depend on operator-name-based lookups;
see for instance the recent complaints over stuff like IS DISTINCT FROM
failing for types whose operators aren't in the search path.
Agreed, but in a way that's not what we're doing here; we're trying to utilize
an operator the user asked us to use. Of course, array_eq assumes that we want
equality; I think that's a problem itself. rowtypes suffer from this too, but
presumably it's not as big a deal because we require typid's to match exactly.
It's arguable that the typcache code should be taught to look for
binary-compatible opclasses if it can't find one directly for the
specified type. I'm not sure offhand what rules we'd need to make
to ensure such a search would yield deterministic results, though.
The risk I see is what happens when someone adds a new operator or cast and
suddenly we have multiple paths. That should be fine for regular comparisons,
but probably not in an index.
Another possibility is that we might be able to extend the "text_ops"
btree operator family to include an opclass entry for varchar, rather than
relying on binary compatibility to find the text opclass. But that would
also require some careful thought to understand what the relaxed
invariants should be for the opfamily structure as a whole. We don't want
to add more actual operators, for fear of creating ambiguous-operator
lookup failures.
Yeah, to me that sounds like heading back down the road of assuming = means =
and the other fun we had before classes and families... but maybe I'm just
being paranoid.
I have an alternative idea, though I'm not sure it's worth the work. Instead of
having special array-only operators we could instead apply regular operators to
arrays. I believe we can do this and reuse existing operators, if we store an
expression of how to combine the result from the previous iteration to the current
one (ie: for < this would be (prev AND current), if there is a result value
that should stop iteration (for comparison operators that would be false), and
what to do with different size arrays. In the last case, you're either going to
use that to provide a final result, substitute a specific value for any missing
elements, or throw an error.
Pros:
With some additional information in the catalog, we could provide a lot more
array operations, using existing operator functions.
We can use the same operator search logic we use for elements. If you can
perform an operation on 2 elements and that operator has array support, then
we're good to go. If we'd perform casting on the elements, we'd do the same
casting with the array values.
We no longer need to assume things like = means equal. If text = int actually
meant length(text) = int then as long as that operator had array support you
could do text[] = int[].
This keeps all operator logic together, regardless of whether the input is an
array or a base element. Not
Cons:
Could this cause problems in the planner? Selectivity estimation comes to mind.
transformAExprOp/make_op would need to do something different for arrays,
because the function would need more information. If we can just extend OpExpr
then maybe this isn't a big deal. (A simple grep shows 401 instances of OpExpr
in src/backend).
I don't think we could use this same technique with rowtypes.
We'd still allow for array-specific operators; perhaps that might cause issues
or at least confusion.
--
Jim Nasby, Data Architect, Blue Treble Consulting
Data in Trouble? Get it in Treble! http://BlueTreble.com
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
