Re: Rethinking the parameter access hooks for plpgsql's benefit - Mailing list pgsql-hackers

From Peter Geoghegan
Subject Re: Rethinking the parameter access hooks for plpgsql's benefit
Date
Msg-id CAM3SWZSYGOpd4u4uY-H4LBY4tmCePuFsx22QSGbSfGCdvoA04A@mail.gmail.com
Whole thread Raw
In response to Re: Rethinking the parameter access hooks for plpgsql's benefit  (Robert Haas <robertmhaas@gmail.com>)
Responses Re: Rethinking the parameter access hooks for plpgsql's benefit
List pgsql-hackers
On Mon, Mar 9, 2015 at 12:06 PM, Robert Haas <robertmhaas@gmail.com> wrote:
> Yes, I understand.  I don't really have anything more to say about
> this.  Nothing here changes my basic feeling that we need to stop
> putting new irons in the fire and start working hard on taking irons
> out of the fire; and I think most if not all other committers are
> already doing that.  Even to the extent that they are focusing on
> their own patches rather than other people's patches, I think it is
> mostly patches that they wrote some time ago, not new things that they
> have only just written.

I must say that I share your concern here. I have no idea what's going
to happen with my ON CONFLICT patch, 9.5-wise. I hope that at least
the IGNORE variant makes it into 9.5, but I'm not sure that it will.

The ON CONFLICT IGNORE/UPDATE patch has existed in essentially the
same form since August, although research level work went into that
project as long ago as 2012. I'm not blaming anyone, but it's quite
discouraging that it has taken so much to get it to where it is now,
even though it's something that there is a huge, tangible demand for
(few other things are in the same category, and few of those have
actually been implemented). An enormous amount of effort went into
internals documentation (the Wiki pages), and into stress-testing
(Jeff Janes' "double entry bookkeeping" stress test, among others). I
hate to say it, but at some point I'll need to cut my loses.

To any interested contributor: If there is something that I can do to
help to advance the state of the ON CONFLICT UPDATE patch, let me
know. Perhaps there can be some useful reciprocal arrangement with
review time. That's not ideal, but I see no alternative.
-- 
Peter Geoghegan



pgsql-hackers by date:

Previous
From: Robert Haas
Date:
Subject: Re: Rethinking the parameter access hooks for plpgsql's benefit
Next
From: Andrew Gierth
Date:
Subject: Re: Calling for a replacement committer for GROUPING SETS