"Kevin Grittner" <kevin.gritt...@wicourts.gov> writes: > Tom Lane <t...@sss.pgh.pa.us> wrote: >> it needs to check the tuple's cmax [...] And that means the patch >> will be a bit more invasive than this, because heap_update and >> heap_delete don't return that information at present. > I'm thinking that I could keep the test for: > GetCurrentCommandId(false) != estate->es_output_cid > as a "first pass". If that's true, I could use EvalPlanQualFetch() > to find the last version of the tuple, and generate the error if the > tuple's cmax != estate->es_output_cid. I think, although I'm not > entirely sure, that EvalPlanQualFetch needs a little work to support > this usage. > Attached is a patch based on these thoughts. Is it on the right > track? I suspect I haven't got everything covered, but thought a > reality check was in order at this point.
You forgot to attach the patch, but the approach seems totally Rube Goldberg to me anyway. Why not just fix heap_update/heap_delete to return the additional information? It's not like we don't whack their parameter lists around regularly. Rather than having three output parameters to support the case, I'm a bit inclined to merge them into a single-purpose struct type. But that's mostly cosmetic. regards, tom lane -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers