| From: | Greg Stark <stark(at)mit(dot)edu> |
|---|---|
| To: | Peter Geoghegan <peter(at)2ndquadrant(dot)com> |
| Cc: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, PG Hackers <pgsql-hackers(at)postgresql(dot)org>, Robert Haas <robertmhaas(at)gmail(dot)com> |
| Subject: | Re: sortsupport for text |
| Date: | 2012-06-20 14:37:30 |
| Message-ID: | CAM-w4HPPq4XOmWw8VRmHqBBnJLQf8XacXvu=jn3b0vsV65sKLw@mail.gmail.com |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
On Wed, Jun 20, 2012 at 3:19 PM, Peter Geoghegan <peter(at)2ndquadrant(dot)com> wrote:
>> It occurs to me that strxfrm would answer this question. If we made
>> the hash function hash the result of strxfrm then we could make
>> equality use strcoll and not fall back to strcmp.
>
> What about per-column collations?
Well collations aren't really per-column, they're specific to the
comparison in the expression at hand. The per-column collation is just
the default for comparisons against that column.
So for a hash join for example you would use build the hash table
using strxfrm for the collation being used for the join expression.
For hash indexes the index would only be valid for a specific
collation, just like a btree index is.
But this all seems like a lot of work for a case that most locales
seem to think isn't worth worrying about.
--
greg
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Matheus Ricardo Espanhol | 2012-06-20 14:53:00 | Re: [HACKERS] PANIC while doing failover (streaming replication) |
| Previous Message | Simon Riggs | 2012-06-20 14:35:47 | Re: [PATCH 10/16] Introduce the concept that wal has a 'origin' node |