Re: Rethinking the parameter access hooks for plpgsql's benefit

From: Andres Freund <andres(at)2ndquadrant(dot)com>
To: Peter Geoghegan <pg(at)heroku(dot)com>
Cc: Robert Haas <robertmhaas(at)gmail(dot)com>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, "pgsql-hackers(at)postgresql(dot)org" <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Rethinking the parameter access hooks for plpgsql's benefit
Date: 2015-03-09 23:03:56
Message-ID: 20150309230356.GE22823@awork2.anarazel.de
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On 2015-03-09 13:15:59 -0700, Peter Geoghegan wrote:
> 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.

FWIW, I think you actually don't have much reason to complain. This work
has probably gotten more attention in total than any other recent
patch. Certainly, by far, more than any other in the 9.5 cycle.

So far I've not seen a single version that could be considered 'ready
for committer'. Even if there's points to be resolved you can make one
(presumably yours) solution ready.

Greetings,

Andres Freund

--
Andres Freund http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Peter Geoghegan 2015-03-09 23:06:11 Re: Documentation of bt_page_items()'s ctid field
Previous Message Jeff Janes 2015-03-09 22:51:57 Re: Documentation of bt_page_items()'s ctid field