Subject | Re: [Firebird-Architect] REPLACE, again |
---|---|
Author | Nando Dessena |
Post date | 2006-08-25T13:32:04Z |
Jim, all,
J> <field_list> must contain the primary key
why? Matching on a secondary key and having a before insert trigger
generate the primary key on insert, while not something I do very
often myself, looks reasonable to me.
Plus, injecting smartness in the verb, which becomes aware of the
primary key and dependant on it, would look inconsistent with the rest
of the language to me.
Finally, if an established syntax (MERGE in the SQL standard) exists,
although cumbersome and/or seemingly too complex for most uses,
inventing an additional verb seems wrong to me. It would be better to
partially support the MERGE statement than creating a smaller brother.
My 2c.
--
Nando Dessena
>>> REPLACE INTO <table> [(<field_list>)] VALUES (<value_list>) MATCHINGJ> The MATCHING clause makes no sense, even if you do like it, since the
>>> (<field_list>) [RETURNING <value_list>]
J> <field_list> must contain the primary key
why? Matching on a secondary key and having a before insert trigger
generate the primary key on insert, while not something I do very
often myself, looks reasonable to me.
Plus, injecting smartness in the verb, which becomes aware of the
primary key and dependant on it, would look inconsistent with the rest
of the language to me.
Finally, if an established syntax (MERGE in the SQL standard) exists,
although cumbersome and/or seemingly too complex for most uses,
inventing an additional verb seems wrong to me. It would be better to
partially support the MERGE statement than creating a smaller brother.
My 2c.
--
Nando Dessena