WIP patch: collation assignment algorithm rewrite - Mailing list pgsql-hackers

From Tom Lane
Subject WIP patch: collation assignment algorithm rewrite
Date
Msg-id 19105.1300569759@sss.pgh.pa.us
Whole thread Raw
Responses Re: WIP patch: collation assignment algorithm rewrite
List pgsql-hackers
Attached is a WIP patch to split the expression-tree representation of
collations into separate fields for input and output collation, and to
replace the parser's current method of assigning collations with a
recursive post-pass.  I need to read over it again before committing,
but I think it's pretty close to ready.

One slightly annoying aspect of this change is that there are assorted
utility commands that call transformExpr() for themselves, and these
places now have to remember to call assign_expr_collations() as well.
I thought about pushing the collations call into transformExpr(), but
most of those call sites also call coerce_to_boolean or other functions
that modify the output of transformExpr, and the collation traversal
has to happen after that.  In any case, the parser uses transformExpr
recursively internally, and a whole lot of further changes would have
been needed to make those internal calls go to a separate entry point.

Other than that it seemed to go pretty smoothly.  One thing I was happy
about was that after adding an output-collation field to RelabelType,
it was possible for the planner to get rid of CollateExpr nodes by
rewriting them as RelabelType.  That means that the existing logic for
ignoring RelabelType when comparing subexpressions is sufficient to
cover cases involving COLLATE labels that might appear on only some of
the subexpressions.  Much of the planner was pretty broken for such
cases before, but I think it mostly works now.

Any comments?

            regards, tom lane


Attachment

pgsql-hackers by date:

Previous
From: Robert Haas
Date:
Subject: Re: sync rep & fsync=off
Next
From: Robert Haas
Date:
Subject: Re: VACUUM FULL deadlock with backend startup