avoid MERGE_ACTION keyword?
Hackorum builds and tests every patch posted to the lists, not only commitfest submissions. This is Hackorum's own CI rather than the PostgreSQL project's, and it is still under testing - please report anything that looks wrong.
Every patchset is also pushed to a branch of our PostgreSQL fork, so you can check out the same tree CI built. Without a PostgreSQL checkout:
git clone --branch t49641_1 https://github.com/hackorum-dev/postgres.gitIn a checkout you already have, add the fork once:
git remote add hackorum https://github.com/hackorum-dev/postgres.gitthen, for this patchset and every later one:
git fetch hackorum t49641_1 && git checkout t49641_1Patchset v1 (message #1) is on t49641_1
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