Horton

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

Tom Lane <tgl@sss.pgh.pa.us>

View thread
From: Tom Lane <tgl@sss.pgh.pa.us>
To: Peter Eisentraut <peter_e@gmx.net>
Cc: Andres Freund <andres@anarazel.de>, pgsql-hackers@postgresql.org, Rémi Zara <remi_zara@mac.com>, Stefan Huehner <stefan@huehner.org>
Date: 2011-03-08T22:43:12Z
Lists: pgsql-hackers

Commits

Same data as JSON: GET /api/v1/messages/:b64id/commits the thread's linked commits as JSON, with link sources. API reference →

  1. Further refine patch for commenting operator implementation functions.

  2. Fix citext's upgrade-from-unpackaged script to set its collation correctly.

  3. Mark operator implementation functions as such in their comments.

  4. Add KNNGIST support to contrib/btree_gist.

  5. Fix plpython breakage detected on certain Fedora machines on buildfarm.

Peter Eisentraut <peter_e@gmx.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