Postgres Integer类型的下限超出范围?
per postgres 整数类型是在 -2147483648
和 +2147483647
。
我认为这些边界是包容性的,但是如果我尝试:
select -2147483648 = -2147483648::int4
<代码>整数超出范围错误。
上界似乎正确地施放了:
# select 2147483647 = 2147483647::int4;
?column?
----------
t
(1 row)
如果我增加下限,则它的工作原理也很好:
# select -2147483647 = -2147483647::int4;
?column?
----------
t
(1 row)
将相同的结果应用于 smallint
。
我在这里缺少一些明显的东西,还是在Postgres数字类型中排除了下界?
如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱,如果其他用户或者作者回复了您的评论,将不能在第一时间通知您!
发布评论
评论(1)
tldr : 。
这很棘手。对于
smallint
和bigint
,下界的同样的铸件似乎失败了:但外观在欺骗。这是真正发生的事情:
-
被视为“ Unary sionus” 运算符,仅在 之后才踢::
(“ postgresql style typecast” )。而且由于Integer
(int4
)的范围是-2147483648 to +2147483647
正如您准确引用的那样,该表达式在:db&lt;&gt; fiddle
&
am高效,因为那只是一个演员,不是演员 +否定操作。
您甚至可以:
只是为了推翻操作员的优先级。但是最后一个看起来很尴尬。而且效率略低。 :)
相关:
TLDR: operator precedence.
This is tricky at first sight. The same cast of the lower bound seemingly fails for
smallint
andbigint
, too:But looks are deceiving. This is what really happens:
-
is taken to be "unary minus" operator, which only kicks in after::
(the "PostgreSQL-style typecast"). And since the range ofinteger
(int4
) is-2147483648 to +2147483647
as you quoted accurately, the expression fails at:db<>fiddle here
Use one of these instead:
Also ever so slightly more efficient, since that's just a cast, not a cast + negation operation.
You could even:
Just to overrule operator precedence. But the last one looks awkward. And it's slightly less efficient. :)
Related: