Github user zellerh commented on a diff in the pull request:
https://github.com/apache/incubator-trafodion/pull/380#discussion_r56240661
--- Diff: core/sql/optimizer/BindRelExpr.cpp ---
@@ -10171,17 +10164,26 @@ matched clause of merge). If the upsert caused a
row to be updated in the
base table then the old version of the row will have to be deleted from
indexes, and a new version inserted. Upsert is being transformed to merge
so that we can delete the old version of an updated row from the index.
+
+Upsert is also converted into merge when there are omitted cols with
default values and
+TRAF_UPSERT_WITH_INSERT_DEFAULT_SEMANTICS is set to OFF in case of
aligned format table or
+omitted current timestamp cols in case of non-aligned row format
--- End diff --
Can I suggest two changes - not sure if they are feasible, but let me give
it a try and ask for them.
First, if we have a column with default current: Couldn't we just add an
assignment of the column to current, without transforming the upsert to a merge?
Second, I would find it more clear if we would define UPSERT as something
that either inserts a new row or replaces an entire existing row, but does not
merge old and new rows. If a user wants a merge then that's what the MERGE
command is for.
What would it mean to do that? As far as I can tell, several things:
* Automatically generate an assignment for columns with DEFAULT CURRENT, no
need to transform to MERGE because of that. This applies to both aligned and
non-aligned format.
* No need to transform to MERGE just because we have omitted columns in
aligned format.
* No need for the CQD for aligned format.
* For non-aligned format, do one of two things:
* Always generate all (default) values, even those not specified in the
upsert command.
* Have a CQD (could re-use the one now used for aligned) to suppress
generation of defaults and take a chance to see values from previous rows. This
trades space savings for unclear semantics.
It's a bit late for this kind of design discussion, just want to bring it
up here. If you feel we should go with what you coded that's ok with me, it's a
step up from the current behavior. I can also file a JIRA for want I suggest
and we can do that later.
---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at [email protected] or file a JIRA ticket
with INFRA.
---
