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

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

I came across this, which looks like a bug to me:

{code:sql}
connect 'jdbc:derby:memory:db;create=true';

create table t1(x int);
create table t2(y int);

create trigger tr after insert on t1 referencing new table as new
merge into t2 using new on x = y when matched then update set y = x;
{code}

Results in:

{noformat}
ERROR 42X04: Column 'NEW.Y' is either not in any table in the FROM list or 
appears within a join specification and is outside the scope of the join 
specification or appears in a HAVING clause and is not in the GROUP BY list. If 
this is a CREATE or ALTER TABLE  statement then 'NEW.Y' is not a column in the 
target table.
{noformat}

The message is correct, in the sense that there is no column Y in the NEW 
transition table. But the trigger action never references column Y in the 
transition table, so I don't think it should fail.

It fails the same way even if all the columns are qualified with table names:

{noformat}
ij> create trigger tr after insert on t1 referencing new table as new
merge into t2 using new on new.x = t2.y when matched then update set t2.y = 
new.x;
ERROR 42X04: Column 'NEW.Y' is either not in any table in the FROM list or 
appears within a join specification and is outside the scope of the join 
specification or appears in a HAVING clause and is not in the GROUP BY list. If 
this is a CREATE or ALTER TABLE  statement then 'NEW.Y' is not a column in the 
target table.
{noformat}

NEW.X and T2.Y are the only column references, yet it complains about some 
reference to NEW.Y.

> 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, 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, 
> derby-3155-16-aa-treatCurrentRowLocationNodeLikeBaseColumnNode.diff, 
> derby-3155-17-aa-serializingRowLocations.diff, 
> derby-3155-18-aa-basicView.diff, 
> derby-3155-19-aa-forbidSubqueriesInMatchedClauses.diff, 
> derby-3155-20-aa-reworkColumnMatching.diff, 
> derby-3155-21-ac-cleanupAndForbidSynonyms.diff, 
> derby-3155-22-ad-testIdentifiersOnLeftSideOfSetClauses.diff, 
> derby-3155-23-aa-forbidDerivedColumnLists.diff, 
> derby-3155-24-aa-supportParameters.diff, 
> derby-3155-25-aa-parametersAsInsertValues.diff, 
> derby-3155-26-aa-copyRowLocationForIndexScans.diff, 
> derby-3155-27-aa-adjustMatchingRefinements.diff, 
> derby-3155-28-aa-cardinalityViolations.diff, 
> derby-3155-29-aa-missingSchema.diff, 
> derby-3155-30-ab-moreCorrelationNames.diff, 
> derby-3155-31-aa-deletePrivs.diff, derby-3155-32-aa-newTestFunction.diff, 
> derby-3155-33-ab-insertPrivs.diff, derby-3155-34-aa-updatePrivs.diff, 
> derby-3155-34-ab-updatePrivs.diff, derby-3155-35-aa-allPrivsTest.diff, 
> derby-3155-36-aa-lockModeComment.diff, derby-3155-37-aa-printSubNodes.diff, 
> derby-3155-38-aa-datatypes.diff, derby-3155-39-aa-fixBuild.diff, 
> derby-3155-40-aa-bigLobs.diff, derby-3155-41-aa-nullGeneratedColumns.diff, 
> derby-3155-42-aa-triggersAndGeneratedColumns.diff, 
> derby-3155-43-aa-eliminateDuplicateColumnRefs.diff, 
> derby-3155-44-aa-lobsInTriggers.diff, derby-3155-45-aa-serialization.diff, 
> derby-3155-46-aa-deferredDeletes.diff, derby-3155-47-aa-collations.diff, 
> derby-3155-48-aa-indexScan.diff, derby-3155-49-aa-cleanup1.diff, 
> derby-3155-50-aa-revampDeleteThenRows.diff, derby-3155-51-aa-cleanup2.diff, 
> derby-3155-52-aa-upgrade.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.2#6252)

Reply via email to