Re: Alpha4 release blockers (was Re: wrapping up this CommitFest) - Mailing list pgsql-hackers

From Tom Lane
Subject Re: Alpha4 release blockers (was Re: wrapping up this CommitFest)
Date
Msg-id 505.1299624192@sss.pgh.pa.us
Whole thread Raw
In response to Re: Alpha4 release blockers (was Re: wrapping up this CommitFest)  (Peter Eisentraut <peter_e@gmx.net>)
Responses Re: Alpha4 release blockers (was Re: wrapping up this CommitFest)
List pgsql-hackers
Peter Eisentraut <peter_e@gmx.net> writes:
> On mån, 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


pgsql-hackers by date:

Previous
From: Peter Eisentraut
Date:
Subject: Re: Alpha4 release blockers (was Re: wrapping up this CommitFest)
Next
From: Peter Eisentraut
Date:
Subject: Re: Theory of operation of collation patch