On Tue, Oct 24, 2023 at 2:11 PM Jeff Davis <pg...@j-davis.com> wrote:
> On Wed, 2023-08-23 at 11:58 +0100, Dean Rasheed wrote: > > Updated version attached, fixing an uninitialized-variable warning > > from the cfbot. > > I took another look and I'm still not comfortable with the special > IsMergeSupportFunction() functions. I don't object necessarily -- if > someone else wants to commit it, they can -- but I don't plan to commit > it in this form. > > Can we revisit the idea of a per-WHEN RETURNING clause? The returning > clauses could be treated kind of like a UNION, which makes sense > because it really is a union of different results (the returned tuples > from an INSERT are different than the returned tuples from a DELETE). > You can just add constants to the target lists to distinguish which > WHEN clause they came from. > > I know you rejected that approach early on, but perhaps it's worth > discussing further? > Yeah. Side benefit, the 'action_number' felt really out of place, and that neatly might solve it. It doesn't match tg_op, for example. With the current approach, return a text, or an enum? Why doesn't it match concepts that are pretty well established elsewhere? SQL has a pretty good track record for not inventing weird numbers with no real meaning (sadly, not so much the developers). Having said that, pg_merge_action() doesn't feel too bad if the syntax issues can be worked out. Very supportive of the overall goal. merlin