[ 
https://issues.apache.org/jira/browse/DERBY-3155?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13877519#comment-13877519
 ] 

Knut Anders Hatlen commented on DERBY-3155:
-------------------------------------------

Thanks for that clarification. My original understanding of that bullet was 
that the exposed name of the source table had to be different from the exposed 
name of the target table.

The assert failure that I posted just before the question about self merge, was 
something I originally came across while trying to work around the limitation. 
For example, this would allow you to do a self merge, but currently fails just 
like the repro above:

{noformat}
ij> create table t(x int, y int);
0 rows inserted/updated/deleted
ij> create view v as select * from t;
0 rows inserted/updated/deleted
ij> merge into t using v on t.x=v.x when matched then update set t.y=v.y;
ERROR XJ001: Java exception: 'ASSERT FAILED currentOfNode is null: 
org.apache.derby.shared.common.sanity.AssertFailure'.
{noformat}

> Support for SQL:2003 MERGE statement
> ------------------------------------
>
>                 Key: DERBY-3155
>                 URL: https://issues.apache.org/jira/browse/DERBY-3155
>             Project: Derby
>          Issue Type: Improvement
>          Components: SQL
>            Reporter: Trejkaz
>            Assignee: Rick Hillegas
>              Labels: derby_triage10_10
>         Attachments: MergeStatement.html, MergeStatement.html, 
> MergeStatement.html, derby-3155-01-ac-grammar.diff, 
> derby-3155-02-ag-fixParserWarning.diff, 
> derby-3155-03-ae-backingStoreHashtableWithRowLocation.diff, 
> derby-3155-03-af-backingStoreHashtableWithRowLocation.diff, 
> derby-3155-03-ag-backingStoreHashtableWithRowLocation.diff, 
> derby-3155-03-ah-backingStoreHashtableWithRowLocation.diff, 
> derby-3155-04-ae-deleteAction.diff, derby-3155-04-af-deleteAction.diff, 
> derby-3155-05-aa-triggerTransitionTableAsTarget.diff, 
> derby-3155-06-aa-triggerTransitionTableAsSource.diff, 
> derby-3155-07-ad-insertAction.diff, derby-3155-08-ah-updateAction.diff, 
> derby-3155-09-aa-correlationNames.diff, 
> derby-3155-10-aa-correlationNames.diff, 
> derby-3155-11-ab-beforeTriggersCantFireMerge.diff, 
> derby-3155-12-aa-canOmitInsertColumnList.diff, 
> derby-3155-13-aa-allowSystemAndTempTables.diff, 
> derby-3155-14-aa-replaceCorrelationNamesOnLeftSideOfSETclauses.diff, 
> derby-3155-15-aa-replumbMergeResultSetCleanup.diff
>
>
> A relatively common piece of logic in a database application is to check for 
> a row's existence and then either update or insert depending on its existence.
> SQL:2003 added a MERGE statement to perform this operation.  It looks like 
> this:
>     MERGE INTO table_name USING table_name ON (condition)
>     WHEN MATCHED THEN UPDATE SET column1 = value1 [, column2 = value2 ...]
>     WHEN NOT MATCHED THEN INSERT column1 [, column2 ...] VALUES (value1 [, 
> value2 ...]) 
> At the moment, the only workaround for this would be to write a stored 
> procedure to do the same operation, or to implement the logic client-side.



--
This message was sent by Atlassian JIRA
(v6.1.5#6160)

Reply via email to