Huan Du

什么时候有更多的信息呢？ @Torwang1

可以考虑直接使用 `InsertBuilder` 的 `SQL()` 方法来实现，毕竟一般 update 后面跟的表达式里面也没什么值得 escape 东西，一般都是固定的一个字符串。如果业务上使用觉得麻烦，可以在业务层对 `InsertBuilder` 做个简单封装。

我明白你的意思了，不过ON DUPLICATE KEY UPDATE 这个的语法其实还有点麻烦。你这里写的是 MySQL 的语法，而 [PostgreSQL 的语法](https://www.postgresql.org/docs/devel/sql-insert.html)是 ON CONFLICT，[SQLite 的语法](https://www.sqlite.org/lang_UPSERT.html)是 ON CONFLICT(index_column)，差异极大，比较难做成不同风格（flavor）的统一。 暂时没有想到太好的解法，一种可能性是扩展 `InsertBuilder#SQL()` 方法的能力，允许在里面使用变量，类似现在的 `Build()` 方法，这需要对底层的机制做一些升级，当然也需要对所有支持 `SQL()` 方法的 builder 都要进行升级。这样，业务代码自行做 ON DUPLICATE KEY UPDATE 的封装就好了。

> 持保留态度, SQL() 提供了过度的灵活性 我也是觉得不太好，所以现在我还没想到比较好的方案，没有动手去改。 这个库最初引入 flavor 的设计想法，就是想有限度的抹平不同 SQL 系统之间的语法细微差异，实现通用易读的拼接语法，不过面对现在这个 ON DUPLICATE KEY 已经有点为难了，这是一种非标准（并不在 SQL ISO 标准里）且各家语法都不一样（仔细看差异还很大），要想用 flavor 统一几乎不可能了，如果实现出 `ON CONFLICT IGNORE` 和 `ON CONFLICT SET`，那么 MySQL 用户肯定不太能看懂，PostgreSQL 和 SQLite...

Thanks for letting me know this. I'll take a look at it later.

Let's discuss this issue in [sirupsen/logrus#904](https://github.com/sirupsen/logrus/issues/904).

LGTM. Thanks for your contribution!

@croconut There is nothing blocking us to build such SQL with current API. At the application level, we can call `SQL()` on `SelectBuilder` to build any arbitrary SQL including ON...

> How about make a function like *ExceptTag similar to *ForTag? Can you please provide a sample to let me know what the `*ExceptTag` method will do? I don't quite...

> But, when we have function like UpdateExceptTag then I can replace above like this, @wangmir I got your point and add a new method `WithoutTag` in `Struct` to address...