You should look for both sql_command type and lex->ignore value (both
are part of thd->lex->sql_command and thd->lex->ignore) to determine
if the storage engine can safely return success on dup cases. But
remember, doing so will result in wrong stats (number of rows
inserted/updated)
Apart from insert/replace, load data also uses the same logic.
On Tue, Feb 23, 2010 at 12:07 PM, Zardosht Kasheff <zardosht@stripped> wrote:
>
> Hello,
>
> Does anyone have any guidance here?
>
> Thanks
> -Zardosht
>
> On Wed, Feb 17, 2010 at 3:47 PM, Zardosht Kasheff <zardosht@stripped> wrote:
> > So it seems that just looking at this flag will not work, because
> > INSERT IGNORE and INSERT...ON DUPLICATE KEY UPDATE both set this flag.
> >
> > I guess what I am wondering is the following, is there any way for the
> > handler to know for sure that the user has called "insert ignore", and
> > if so, would it be ok for the handler to return success even if
> > internally a duplicate key is found?
> >
> > Thanks
> > -Zardosht
> >
> > On Fri, Feb 12, 2010 at 5:08 PM, Zardosht Kasheff <zardosht@stripped>
> wrote:
> >> Hello all,
> >>
> >> I am trying to implement an optimization in our storage engine if
> >> HA_EXTRA_IGNORE_DUP_KEY is set. Would it be ok if handler::write_row
> >> returns success if this flag is set, the sql statement is NOT
> >> SQLCOM_REPLACE or SQLCOM_REPLACE_SELECT, and the row is not inserted
> >> if a duplicate is otherwise there.
> >>
> >> Basically, the question is if this flag is set, is it ok to not return
> >> HA_ERR_FOUND_DUPP_KEY in the cases where the statement is not "replace
> >> into".
> >>
> >> Thanks
> >> -Zardosht
> >>
> >
>
> --
> MySQL Internals Mailing List
> For list archives: http://lists.mysql.com/internals
> To unsubscribe: http://lists.mysql.com/internals?unsub=1
>
