On Thu, Apr 5, 2012 at 2:17 PM, Simon Riggs <simon@2ndquadrant.com> wrote:
> On Thu, Apr 5, 2012 at 7:00 PM, Robert Haas <robertmhaas@gmail.com> wrote:
>> On Thu, Apr 5, 2012 at 1:28 PM, Simon Riggs <simon@2ndquadrant.com> wrote:
>>> These patches aren't marked with a committer
>>>
>>> FK arrays
>>> ECPG fetch
>>> foreign stats
>>> command triggers
>>> check function
>>> parallel pg_dump
>>>
>>> Does that mean myself or others should be claiming them for commit/reject?
>>
>> I've been right in the middle of the command triggers stuff, so I
>> suppose I would pick that up for commit if it were ready, but there
>> hasn't been a new version this week unless I've missed it, and even if
>> the new version arrived right this minute, I don't think I or anyone
>> else can do a good job committing a patch of that size in the time
>> remaining. So I think it's time to formally put that one out of its
>> misery.
>
> I think doing so will cause substantial misery for many users. I find
> it hard to believe that such a simple concept hasn't managed to
> produce some workable subset after months of work.
I am not interested in relitigating on this thread what has already
been extensively discussed nearby. Dimitri and I agreed on numerous
changes to try to make the behavior sane, and those changes were
suggested and agreed to for good reason. We didn't agree on every
point, of course, but we did agree on most of it, and there is no
patch that implements what was agreed. Even if there were, there is
not time to review and commit a heavily revised version of a >1000
line patch before tomorrow, and any suggestion to the contrary is just
plain wrong.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company