Thread: disposition of remaining patches

disposition of remaining patches

From
Robert Haas
Date:
Looking over the remaining patches that still aren't closed in the
January CommitFest:

Foreign keys with arrays - Tom wants to commit this at the beginning
of a release cycle rather than the end, but there's no actual known
problem with it.  Therefore I suggest moving it to the first 9.3
CommitFest.

ECPG FETCH readahead - Michael Meskes is going to commit this soon;
everyone seems to agree it's ready to go.

pgsql_fdw contrib module - It seems like this is still in the midst of
discussions about what the behavior should be, so it seems like
Returned with Feedback is the only place for it to go.

check function statement - Heikki stated that he isn't comfortable
committing this because it's got too much duplicative code, so I think
we should mark Returned with Feedback until someone does some more
work in that area.

Add timing of buffer I/O requests - This is basically committed, but I
have an outstanding question which I just posted on the relevant
thread.

URI connection string support for libpq - I'm unclear with Alvaro or
Peter still intend to try to slip this one in.  It's simple enough
that I think that would be OK if it can be done in the next day or
two.  Otherwise, 9.3.

parallel pg_dump - I think this one needs to get moved to the first
9.3 CommitFest.  There is more work to be done there than we can
realistically do right now, but I think we can pick it up for the next
cycle.

Thoughts/comments?

-- 
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company


Re: disposition of remaining patches

From
Andrew Dunstan
Date:

On 04/10/2012 09:40 AM, Robert Haas wrote:
>
> parallel pg_dump - I think this one needs to get moved to the first
> 9.3 CommitFest.  There is more work to be done there than we can
> realistically do right now, but I think we can pick it up for the next
> cycle.
>


Yeah, I'm only about 1/4 of the way through it :-(

cheers

andrerw


Re: disposition of remaining patches

From
Tom Lane
Date:
Robert Haas <robertmhaas@gmail.com> writes:
> Looking over the remaining patches that still aren't closed in the
> January CommitFest:
> [ all but ECPG readahead and maybe libpq URIs have to go to 9.3 ]

Yeah, I agree.  I'm not comfortable with squeezing in the array foreign
keys stuff at this point, and the others are clearly not ready.

I put the buffer I/O timing units issue on the open-items list
yesterday:
http://wiki.postgresql.org/wiki/PostgreSQL_9.2_Open_Items
and I encourage people to start using that to track must-fix-for-9.2
items.

We should at this point be focusing our efforts on getting a beta out.
Some but perhaps not all of the open items have to be resolved before
beta1, and we definitely need at least draft-quality release notes
so beta testers know what to test.  Any other must-do tasks out there?
        regards, tom lane


Re: disposition of remaining patches

From
Michael Meskes
Date:
On Tue, Apr 10, 2012 at 09:40:58AM -0400, Robert Haas wrote:
> ECPG FETCH readahead - Michael Meskes is going to commit this soon;
> everyone seems to agree it's ready to go.

It still needs a couple minor tweaks but I think it will be done shortly.

Michael
--
Michael Meskes
Michael at Fam-Meskes dot De, Michael at Meskes dot (De|Com|Net|Org)
Michael at BorussiaFan dot De, Meskes at (Debian|Postgresql) dot Org
Jabber: michael.meskes at googlemail dot com
VfL Borussia! Força Barça! Go SF 49ers! Use Debian GNU/Linux, PostgreSQL


Re: disposition of remaining patches

From
Alvaro Herrera
Date:
Excerpts from Robert Haas's message of mar abr 10 10:40:58 -0300 2012:

> URI connection string support for libpq - I'm unclear with Alvaro or
> Peter still intend to try to slip this one in.  It's simple enough
> that I think that would be OK if it can be done in the next day or
> two.  Otherwise, 9.3.

I intend to commit this today, unless someone is still unhappy with the
choice of syntax.

--
Álvaro Herrera <alvherre@commandprompt.com>
The PostgreSQL Company - Command Prompt, Inc.
PostgreSQL Replication, Consulting, Custom Development, 24x7 support