Thread: avoid MERGE_ACTION keyword?

I wonder if we can avoid making MERGE_ACTION a keyword.

I think we could parse it initially as a function and then transform it 
to a more special node later.  In the attached patch, I'm doing this in 
parse analysis.  We could try to do it even later and actually execute 
it as a function, if we could get the proper context passed into it somehow.

I'm thinking about this with half an eye on future features.  For 
example, row pattern recognition might introduce similar magic functions 
match_number() and classifier() (somewhat the inspiration for the 
merge_action() syntax), which could use similar treatment.

Thoughts?

On Thu, 16 May 2024 at 15:15, Peter Eisentraut <peter@eisentraut.org> wrote:
>
> I wonder if we can avoid making MERGE_ACTION a keyword.
>

Yeah, there was a lot of back and forth on this point on the original
thread, and I'm still not sure which approach is best.

> I think we could parse it initially as a function and then transform it
> to a more special node later.  In the attached patch, I'm doing this in
> parse analysis.  We could try to do it even later and actually execute
> it as a function, if we could get the proper context passed into it somehow.
>

Whichever way it's done, I do think it's preferable to have the parse
analysis check, to ensure that it's being used in the right part of
the query, rather than leaving that to plan/execution time.

If it is turned into a function, the patch also needs to update the
ruleutils code --- it needs to be prepared to output a
schema-qualified function name, if necessary (something that the
keyword approach saves us from).

Regards,
Dean