谢谢大家的帮助。
@kuanat 衷心感谢，另外我还想问一下，如果我保持版本号不变，那么 tag 不是会冲突么？谢谢

首先谢谢各位的热心解答。

对于抓包，我不是特别能理解。一般来说，抓包是为了进行协议分析而不是内容收集。因为抓包的大多数环境实际上并不能广泛适用，自己 root 一个手机、设置一个环境可以抓包，但是这样的主动环境抓几个包除了分析感觉也做不了啥事情（这样的环境真要搞事情，很多其他的手段，接口上的加解密也没啥太大用）。协议分析的话，接口文档描述得清清楚楚明明白白，应该也用不着。

对于重放，我也觉得不太像。如果加密本身不解决重放的问题，重放密文一样可以攻击。

@ding2dong 好吧，可能是我太老土了，谢谢啦

@wy315700 有道理，多谢啦

@wy315700 参考华为，其实系统可以考虑应用在前台的时候再分发呗。

如今是薛定谔的版本，坐我旁边的哥们，版本号和你我一样，他没有下拉箭头，没有淡紫色标题栏，没有新样式的对话框，也跟我核对了半天.....

@pger 感谢热心回复。

我这里因为是一些工业场合，追求的是固定配置下的大 io 容量。（不像互联网领域，用户量上来了就增加配置，比较弹性）

最后讨论的方案是，锁表然后先查，没有的情况下再插入。这种方式在 conflict 的情况下，只需要查询一次。

再次感谢~

@adoal 谢谢，我的确是接触 pg 不久，原来是这么个历史原因，受教了。看样子得想别的办法了，多查询一次和最初设计的 io 负荷不匹配，得仔细点考虑。搜索了一下，类似的提问还不少，希望有代表民意的大佬们。再次感谢~！

@dw2693734d 感谢大神指导...受益匪浅

UPDATE 会造成写操作；
重新查询会造成读负担；
想咨询有没有好一点的方法，为什么设计成这样，是为了效率么？

我是保存的的不带时区啊：
insert into tabtstest(tsnotz) values('2020-01-01 0:0:0');

@masterclock 嗯，历史遗留问题这个就好理解了。多谢。

@zzzkkk 我是看见有人说保存的是 UTC 时间，我不同意这个说法。
如果保存的是 UTC 时间，那么读取出来应该是`2020-01-01 0:0:0+0`或者`2019-12-31 16:00:00+08`。
明显`AT TIME ZONE 'asia/shanghai'`就是告诉 pg ，这个保存的时间按照`asia/shanghai`来理解，而不是说按照 UTC 来理解。

各位说保存为 utc 的，那么怎么解释这个最后读取的结果是`2019-12-31 16:00:00+00`，这个+00 可不是我指定的。

```
```sql
$ create table tabtstest(id serial primary key, tsnotz timestamp without time zone);
CREATE TABLE

$ insert into tabtstest(tsnotz) values('2020-01-01 0:0:0');
INSERT 0 1

$ select * from tabtstest;
id | tsnotz
----+---------------------
1 | 2020-01-01 00:00:00
(1 row)

$ select tsnotz AT TIME ZONE 'asia/shanghai' from tabtstest;
timezone
------------------------
2019-12-31 16:00:00+00
```

@cxh116 感谢，我就是奇怪 timestamp without zone 有什么实际用途。

代理服务器？

谢谢各位

2023 年，2022H2 ，bug 依旧，无语。

@nieyujiang 本来还想客户端和服务器端如果都用一个语言倒是能减少一些语言切换间的损耗呢。