Question Re: Default semantics for MERGE statement in Technology Q&A

Default semantics for MERGE statement

Former Member — Wed, 03 Nov 2010 01:04:24 GMT

Does MERGE use the same semantics as INSERT does for applying default values for inserted columns that are (a) not provided or (b) provided with NULL values? If not, can someone point to a description of those semantics? (I haven't found them in the online help.)

I realize this sounds like an odd question, but I'm getting odd results, and it would help to know whether to look for a straightforward mistake or if there are more subtle rules that I'm just not taking into account.

(Note: I'm only asking if the MERGE rules are different than for INSERT. I won't subject you all to do my debugging for me.)

Re: Default semantics for MERGE statement

VolkerBarth — Thu, 04 Nov 2010 11:15:59 GMT

Without me knowing the particular rules: As the INSERT/UPDATE/DELETE actions of a MERGE statement are recorded in the transaction log as individual INSERT/UPDATE/DELETE operations, that might give you a clue of what exact operation is executed under the covers.

Re: Default semantics for MERGE statement

VolkerBarth — Fri, 05 Nov 2010 08:13:56 GMT

FWIW: I should have added that DBTRAN will be needed to check the log's contents:)

Re: Default semantics for MERGE statement

MarkCulp — Sat, 06 Nov 2010 00:54:52 GMT

@Dan: Can you elaborate on the "odd results" that you are seeing? AFAIK (and I have not checked the code) when the MERGE statement invokes the INSERT clause for a NOT MATCHED tuple it is equivalent to executing an INSERT statement and therefore should end up inserting the same thing.

Re: Default semantics for MERGE statement

MarkCulp — Sat, 06 Nov 2010 01:21:12 GMT

The MERGE statement uses the same semantics as an INSERT statement when the MERGE's NOT MATCHED INSERT clause is invoked.

Here is an example that illustrates the MERGE statement INSERT clause.

create table foo( i int default autoincrement, s varchar(100) default 'specified', t varchar(100) default 'not specified', u varchar(100) default 'nulls', v varchar(100) default 'defaults' ); merge into foo using ( select row_num from sa_rowgenerator( 1, 4 ) ) as s on foo.i = s.row_num when not matched then insert( i, s, u, v ) values( s.row_num, s.row_num*s.row_num, null, default ); insert into foo( i, s, u, v ) values( 10, 10*10, null, default ); select * from foo;

The output is:

i s t u v 1 1 not specified (NULL) defaults 2 4 not specified (NULL) defaults 3 9 not specified (NULL) defaults 4 16 not specified (NULL) defaults 10 100 not specified (NULL) defaults

Note that when null is given as the value, NULL is inserted (e.g. column u), and when the column is omitted from the insert clause (e.g. column t) or when 'default' is given as the value of the column (e.g. column v) then the default value (e.g. column v's default is 'defaults') is inserted into the row. This is the same behaviour as is seen when the value was inserted by an INSERT statement (e.g. row where i = 10)