Skip site navigation (1) Skip section navigation (2)

WIP patch: collation assignment algorithm rewrite

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: pgsql-hackers(at)postgreSQL(dot)org
Subject: WIP patch: collation assignment algorithm rewrite
Date: 2011-03-19 21:22:39
Message-ID: (view raw, whole thread or download thread mbox)
Lists: 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: collation-fixes-1.patch.gz
Description: application/octet-stream (61.2 KB)


pgsql-hackers by date

Next:From: Robert HaasDate: 2011-03-20 03:15:10
Subject: Re: VACUUM FULL deadlock with backend startup
Previous:From: Robert HaasDate: 2011-03-19 20:31:19
Subject: Re: sync rep & fsync=off

Privacy Policy | About PostgreSQL
Copyright © 1996-2017 The PostgreSQL Global Development Group