On 2014-06-09 10:30:43 -0400, Tom Lane wrote: > Andres Freund <and...@2ndquadrant.com> writes: > > On 2014-06-09 10:14:32 -0400, Robert Haas wrote: > >> I think that would be a good idea for conceptual clarity if nothing > >> else. If callers are OK with it, then they can treat both of those > >> codes alike; but then at least there's clear evidence as to the > >> author's intent. > > > I am happy to introduce the code for that. But it'd have to be >=9.4 or > > 9.4? > > We need a solution that can be back-patched, unless you're prepared to > revert what you already did to HTSV in the back branches.
Well, I think reverting surely wouldn't be the right cure. It fixes a somewhat nasty bug. I'd certainly be prepared to add the two lines necessary to make it return DELETE_IN_PROGRESS after trying to understand Kevin's email about predicate.c and going through the other callers another time. I did ask about what people think is the more appropriate return value. And the only person that had voiced an opinion was Alvaro agreeing that it's more correct to return INSERT_IN_PROGRESS... Don't make this about me insisting on anything. > Having said that, it's not clear to me that we couldn't change HTSV's > API in the back branches. What third-party code would be likely to > be depending on it? I'm not sure. I could imagine tools like pg_repack depending on it (it doesn't). I started to search for external users of the function and have only found a bunch of forks of postgres so far. Several of which I've never heard of before. I think it's more reasonable to return DELETE_IN_PROGRESS in existing branches and then go the new return value in 9.5 or maybe 9.4. Greetings, Andres Freund -- Andres Freund http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Training & Services -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
