Re: Alpha4 release blockers (was Re: wrapping up this CommitFest)

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

In response to

Responses

Browse pgsql-hackers by date

  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)