From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Peter Eisentraut <peter_e(at)gmx(dot)net> |
Cc: | Andres Freund <andres(at)anarazel(dot)de>, pgsql-hackers(at)postgresql(dot)org, Rémi Zara <remi_zara(at)mac(dot)com>, Stefan Huehner <stefan(at)huehner(dot)org> |
Subject: | Re: Alpha4 release blockers (was Re: wrapping up this CommitFest) |
Date: | 2011-03-08 22:43:12 |
Message-ID: | 505.1299624192@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Peter Eisentraut <peter_e(at)gmx(dot)net> writes:
> On mn, 2011-03-07 at 12:40 -0500, Tom Lane wrote:
>> Fair enough, but throwing in fmgr_info_collation(DEFAULT_COLLATION)
>> anytime we have a problem seems to me to introduce the exact same
>> issue. Who's to say that that's really the appropriate value to use?
> It normally isn't the appropriate value to use. It's only appropriate
> if either that particular part of the code doesn't support collations
> yet or it's dealing with some hardcoded catalog lookups or some similar
> case. In most other cases you should be getting the collation passed in
> from somewhere, and if you aren't there is probably some work to do to
> get it there. That's at least sort of the experience from developing
> this.
Mph. Well, I guess in the case of the pg_statistic stats we can declare
by fiat that we calculate the stats according to the default collation.
They'll be a bit off when used for a query that is comparing according
to some other collation, but it's probably no worse than any other
approximation we make in the selectivity code.
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Peter Eisentraut | 2011-03-08 22:54:57 | Re: Theory of operation of collation patch |
Previous Message | Peter Eisentraut | 2011-03-08 22:25:08 | Re: Alpha4 release blockers (was Re: wrapping up this CommitFest) |