Re: support for MERGE

On 2022-Mar-18, Peter Eisentraut wrote:

> I did a cursory read through and want to offer some trivial amendments in
> the attached patches. The 0001 adds back various serial commas, the 0002 is
> assorted other stuff.

Thanks. I've merged these changes into this new v19.

Apart from rebasing on top of current master (which it had conflicts
with), I've also changed strategy for the tuple counters: Andres
complained that the addition of nfiltered3 was too messy, and I have to
agree. After trying to deal with it in other ways, I ended up deciding
that it wasn't worth it, and just added ad-hoc tuple counters to
ModifyTableState. We use this technique in other executor state nodes,
so it's not anything new.

> One functional change I recommend is the tab completion of the MERGE target.
> I think the filtering in Query_for_list_of_mergetargets is a bit too
> particular. For example, if a table is a possible MERGE target, and then
> someone adds a rule, it will disappear from the completions, without
> explanation, which could be confusing. I think we can be generous in what
> we accept and then let the actual parse analysis provide suitable error
> messages. Also, consider forward-compatibility if support for further
> targets is added. I would consider dropping Query_for_list_of_mergetargets
> and just using Query_for_list_of_updatables.

This argument makes sense to me, so I'll be doing that unless somebody
objects to the idea.

> In any case, the min_server_version could be dropped. That is usually only
> used if the query would fail in an older version, but not if the command
> being completed wouldn't work. For example, we don't restrict in what
> versions you can complete partitioned indexes.

Too true, too true ...

--
Álvaro Herrera 39°49'30"S 73°17'W — https://www.EnterpriseDB.com/
"El sudor es la mejor cura para un pensamiento enfermo" (Bardia)