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

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

From: Tom Lane <tgl@sss.pgh.pa.us>
To: "David E. Wheeler" <david@kineticode.com>
Cc: Josh Berkus <josh@agliodbs.com>, pgsql-hackers@postgresql.org
Date: 2011-03-01T21:38:26Z
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.

"David E. Wheeler" <david@kineticode.com> writes:
> On Mar 1, 2011, at 1:12 PM, Tom Lane wrote:
>> The question is what collation property the
>> citext type needs to have, and how we get it to have that setting during
>> an upgrade from 9.0.  See
>> http://archives.postgresql.org/message-id/11548.1297983024@sss.pgh.pa.us

> Ah, I remember now. That lead to this:

>  http://archives.postgresql.org/pgsql-hackers/2011-02/msg01824.php

> So it looks like what Peter said about updating the catalog is what needs to be done, and is simple, yes? But then pg_dump needs more collation-juju. Am I right?

Yeah, the real problem in my mind is not so much citext as whether the
current representation of a type's collation property is sane in the
first place.  Once we've thrashed that out, I'll be happy with a simple
"UPDATE pg_type" kluge in the citext upgrade script.  Doing anything
cleaner-looking than that is a future project (and might never happen,
seeing that we've never felt a need for ALTER TYPE commands for other
properties of a basic type).

So really I guess the release-blocker issue is
http://archives.postgresql.org/message-id/27152.1299015062@sss.pgh.pa.us

			regards, tom lane