PostgreSQL 没有 on update current_timestamp 感觉好麻烦

最好还是通过程序实现，事件机制，SQL 拦截器都不错
而且这些机制不仅可以做时间的自动刷新，还可以自动刷新最后修改者之类的

除非有大量直接上数据库手改的数据的需求，否则 on update 这种意义不大

一般业务开发不建议依赖 db 的触发器或者`on update`机制，因为不够对开发人员来说不够清晰直观，排查问题时需要去检查 db schema 。

确实是个遗憾。不过已经习惯让 ORM 负责这些琐事了，或者在代码逻辑里简单封装一层。

用 ORM 不存在这些问题

想开一点，每个表都要创建一个 trigger ，只是操作上的麻烦一点，而且也只是一次性的。如果你团队里的人都认可这个事应该用数据库的机制做，那就不是啥麻烦。真正的麻烦是，你觉得应该用数据库的机制做，而其它人都觉得：程序员这种生物就应该把所有的事都放在编程的框架里做；程序员这种生物不是 DBA ，不熟悉也不应该熟悉特定数据库的高级 feature ，用编程语言框架才是自己吃饭的工具；咱们的业务虽然 QPS 不到 10 个但是应该按照双 11 的伸缩性不准酱表不准吹歌不准物理外键……相比之下，数据库端自动触发操作是用语法还是用触发器的差别连细节分歧都算不上。

@adoal 不得不说世界就是一个圈，古时候上大学的时候讲数据库 3 范式，后面上班了发现即使是最传统的 erp 行业，存储过程能写上百行，都不加外键约束。。。在后面微服务的时候讲起来 join 都不能用了，现在 lz 又倒回去想用数据库特性。
前端也是，古时候 jsp/asp/php 都是服务端渲染，几年 spa 之后，现在又开始 react/vue 服务端渲染。

你用 pg 了再用 mysql 才知道多少东西 mysql 没有的。

每个表本来都要有个序列，不在乎多加个触发器

麻烦一点的作法：设置 current_timestamp 列的 default 为 CURRENT_TIMESTAMP ，然后 UPDATE 时 set 下 `current_timestamp = DEFAULT`

ORM 解千愁，数据库是什么，不存在的

@lichao 有个问题一直困扰着我.如果实际用户的表单内容没有发生改变. orm 依旧会生成 updated_at 并更新数据.如果用 mysql 的 on update current_timestamp. 那么 update 的时候 mysql 会自动检测内容是否发生了改变 才去更新数据.不会修改 updated_at 字段..
问题就是 用 orm 接管 一定会更新 updated_at 字段.

@lait123 这种情况是你的 ORM 不够好，这种情况 update 不应该被执行