这是对程序员的某种折磨吗?我无法想象你为什么会这样做。尤其是因为您的 struct-as-a-blob 可能会受到因编译器和平台而异的填充和对齐的影响。即使那样,由于字节顺序的差异,它也会因架构而异。至少你使用了固定宽度的类型。
假设您只关心 little-endian 并且您的编译器不添加任何填充或对齐(可能对于只有 3 个 64 位字段的结构),这是可能的。这不是一个好主意。
我的首选方法是使用带有 struct 的一些 Python 代码,例如
python - "x00911ee3561ac801cb0783462586cf01af00000000000000" <<__END__
import sys
import struct
print "{} {} {}".format(*struct.unpack('@QQQ', sys.argv[1][1:].decode("hex")))
__END__
因为这甚至可以使用适当的修饰符处理字节顺序和打包,并且您可以轻松地在 shell 脚本中使用输出。
如果这不方便/不合适,也可以在 bash 中使用,这绝对是可怕的。对于little-endian,未填充/打包未对齐:
解码每个值(改编自https://stackoverflow.com/a/3678208/398670):
$ x=00911ee3561ac801
$ echo $(( 16#${x:14:2}${x:12:2}${x:10:2}${x:8:2}${x:6:2}${x:4:2}${x:2:2}${x:0:2} ))
所以,对于完整的交易:
x=x00911ee3561ac801cb0783462586cf01af00000000000000
uint64_dec() {
echo $(( 16#${1:14:2}${1:12:2}${1:10:2}${1:8:2}${1:6:2}${1:4:2}${1:2:2}${1:0:2} ))
}
uint64_dec ${x:1:16}
uint64_dec ${x:17:16}
uint64_dec ${x:33:16}
产生:
128381549860000000
130470408871937995
175
现在,我觉得很脏,需要去洗。我强烈建议如下:
CREATE TYPE my_struct AS (a numeric, b numeric, c numeric);
然后使用my_struct 而不是bytea 字段。或者只使用三个numeric 列。您不能使用bigint,因为 Pg 没有 64 位无符号整数。