I wrote:
On further reflection, I'm wondering exactly how much goodness to chop
off there. What I'd originally been thinking was to just lobotomize the
case-folding step, and allow citext's comparison operators to still
respond to input collation when comparing the folded strings. However,
On Jun 6, 2011, at 4:35 PM, Tom Lane wrote:
That sounds like a good idea.
BTW, it struck me shortly after sending this that we'd already discussed
the idea of a flag in pg_proc showing whether a function pays attention
to collation. We could of course use that for this purpose.
Seems like
On Mon, Jun 6, 2011 at 9:14 PM, Tom Lane t...@sss.pgh.pa.us wrote:
The most workable alternative that I can see is to lobotomize citext so
that it always does lower-casing according to the database's default
collation, which would allow us to pretend that its notion of equality
is not
Greg Stark gsst...@mit.edu writes:
On Mon, Jun 6, 2011 at 9:14 PM, Tom Lane t...@sss.pgh.pa.us wrote:
The most workable alternative that I can see is to lobotomize citext so
that it always does lower-casing according to the database's default
collation, which would allow us to pretend that its
I've been looking into bug #6053, in which Regina Obe complains that
hash-based DISTINCT queries fail for type citext. The cause is not
far to seek: the header comment for execGrouping.c states
* Note: we currently assume that equality and hashing functions are not
* collation-sensitive, so
On Jun 6, 2011, at 1:14 PM, Tom Lane wrote:
The most workable alternative that I can see is to lobotomize citext so
that it always does lower-casing according to the database's default
collation, which would allow us to pretend that its notion of equality
is not collation-sensitive after all.
David E. Wheeler da...@kineticode.com writes:
On Jun 6, 2011, at 1:14 PM, Tom Lane wrote:
... One bit of infrastructure that might be a good idea is
a flag to indicate whether an equality operator's behavior is
potentially collation-dependent, so that we could avoid taking
performance hits
