游乐游手机版
首页/数据库/文章详情

PostgreSQL数据库中将doubleprecision字段类型改为BIGINT的完整方法步骤

时间:2026-07-21 21:40
PostgreSQL中修改字段类型可使用ALTERTABLE语句,将doubleprecision转换为BIGINT时需指定USING子句进行类型转换,并同步更新默认值。转换默认按四舍五入处理,如需截断小数可使用trunc函数。生产环境操作前建议备份数据,注意检查是否存在小数。

一、背景说明

在 PostgreSQL 的实际运维中,调整字段类型算是一个高频操作。业务一变,数据类型就得跟着改——比如某个价格字段,原本设计成 double precision(浮点数),后来发现业务里根本不需要小数,干脆换成 BIGINT(大整数)。这件事听着简单,但真要动手,还是有几个坑需要注意。

PostgreSQL修改字段类型之将doubleprecision改为BIGINT的方法步骤

今天就用一张实际业务表来演示,怎么把 double precision 改成 BIGINT,顺便把默认值也一块儿处理利索。

二、示例表结构

假设我们有一张表叫 public.example_price_change_log,里面有个字段 new_value,当前类型是 double precision。想看看表长什么样?用 \d+ 命令就行:

\d+ public.example_price_change_log

输出长这样:

Table "public.example_price_change_log"
Column              | Type
--------------------+------------------
id                  | integer
operator_id         | integer
category_code       | text
new_value           | double precision
effective_time      | bigint
created_time        | bigint
expire_time         | bigint
status              | integer
remark              | text

这次要动刀的就是 new_value 这个字段。

三、修改字段类型的 SQL

PostgreSQL 里改字段类型,标准语法是 ALTER TABLE ... ALTER COLUMN ... TYPE。把 new_valuedouble precision 改成 BIGINT,SQL 如下:

ALTER TABLE public.example_price_change_log
ALTER COLUMN new_value TYPE BIGINT
USING new_value::BIGINT;

这里的关键是 USING new_value::BIGINT——它告诉数据库“用这种方式把旧值转换成新类型”。如果不加 USING,某些类型转换可能报错,所以最好明确写上。

四、同步修改默认值

如果原字段设了默认值,比如 '-1'::integer,改完类型后最好也把默认值统一成 BIGINT

ALTER TABLE public.example_price_change_log
ALTER COLUMN new_value SET DEFAULT -1::BIGINT;

当然,也可以把两步合成一条 SQL:

ALTER TABLE public.example_price_change_log
ALTER COLUMN new_value TYPE BIGINT
USING new_value::BIGINT,
ALTER COLUMN new_value SET DEFAULT -1::BIGINT;

五、修改后的表结构

再跑一遍 \d+,看看成果:

\d+ public.example_price_change_log

输出变成:

Column    | Type   | Default
----------+--------+--------------
new_value | bigint | - 1::bigint

仔细看,默认值显示成了 - 1::bigint,中间多了个空格。别慌,这是 PostgreSQL 对表达式显示格式的“小癖好”,实际含义和 -1::bigint 完全一样,不影响使用。

六、验证字段默认值

如果想更严谨地确认,可以查 information_schema.columns

SELECT column_default
FROM information_schema.columns
WHERE table_schema = 'public'
  AND table_name = 'example_price_change_log'
  AND column_name = 'new_value';

结果可能还是 - 1::bigint,正常现象,不用额外处理。

七、注意事项

1. 修改前建议检查是否存在小数

既然原字段是 double precision,很可能存着小数。转成 BIGINT 之前,先扫一眼到底有没有小数:

SELECT *
FROM public.example_price_change_log
WHERE new_value IS NOT NULL
  AND new_value <> trunc(new_value);

如果查询结果为空,说明没有小数,可以放心转。

2. 默认转换可能会产生取整行为

直接 USING new_value::BIGINT 时,PostgreSQL 会按四舍五入处理。比如:

12.3 -> 12
12.7 -> 13

如果业务不允许自动四舍五入,务必提前确认规则。

3. 如果希望直接截断小数

想截断小数而不是四舍五入?可以用 trunc()

ALTER TABLE public.example_price_change_log
ALTER COLUMN new_value TYPE BIGINT
USING trunc(new_value)::BIGINT,
ALTER COLUMN new_value SET DEFAULT -1::BIGINT;

效果:

12.9 -> 12
12.1 -> 12

4. 生产环境建议先备份

改字段类型属于表结构变更,生产环境执行前最好备份数据。简单点可以建一张备份表:

CREATE TABLE public.example_price_change_log_bak AS
SELECT *
FROM public.example_price_change_log;

或者用 pg_dump 工具,怎么放心怎么来。

八、完整 SQL 示例

方式一:普通转换

ALTER TABLE public.example_price_change_log
ALTER COLUMN new_value TYPE BIGINT
USING new_value::BIGINT,
ALTER COLUMN new_value SET DEFAULT -1::BIGINT;

方式二:截断小数后转换

ALTER TABLE public.example_price_change_log
ALTER COLUMN new_value TYPE BIGINT
USING trunc(new_value)::BIGINT,
ALTER COLUMN new_value SET DEFAULT -1::BIGINT;

九、最终效果

改完之后,字段类型从 double precision 变成 bigint,默认值是 -1::bigint。就算 \d+ 里显示成 - 1::bigint,也完全正常——只是 PostgreSQL 的显示格式问题,里子没变。

十、总结

PostgreSQL 修改字段类型的核心语法就一句话:

ALTER TABLE 表名
ALTER COLUMN 字段名 TYPE 新类型
USING 字段名::新类型;

回到这个案例,把 double precision 改成 BIGINT 的完整示例:

ALTER TABLE public.example_price_change_log
ALTER COLUMN new_value TYPE BIGINT
USING new_value::BIGINT;

如果字段有默认值,最好同步改掉:

ALTER TABLE public.example_price_change_log
ALTER COLUMN new_value SET DEFAULT -1::BIGINT;

最终推荐写法是两者合并,这样字段类型和默认值类型保持一致,后续维护少踩坑。

来源:https://www.jb51.net/database/367720h94.htm
上一篇WSL下MySQL容器跨域权限解决方案 下一篇MongoDB数据库安全加固实战指南:从认证到传输加密
本站内容用于信息整理与展示,如有侵权或内容问题请及时联系处理。

相关推荐

补充同频道和同主题内容,方便继续浏览更多相关内容。

同类最新

继续查看同栏目最近更新的文章。

更多
自增主键值从何而来?深入理解原理,告别只会auto_increment
数据库 · 2026-07-25

自增主键值从何而来?深入理解原理,告别只会auto_increment

KingbaseES推荐使用serial、bigserial、显式sequence或identity列实现自增主键。serial创建integer并关联序列,bigserial对应bigint;显式sequence可自定义起始值等参数;identity有generatedbydefault(允许指定值)与always(禁止)两种模式。

Linux下瀚高数据库授权文件过期及替换解决方案
数据库 · 2026-07-25

Linux下瀚高数据库授权文件过期及替换解决方案

在银河麒麟系统下,瀚高数据库hgdb-4 5试用授权20天到期后需替换正式授权文件。正确操作:停止服务,备份旧文件,将授权文件复制到 opt highgo hgdb-4 5 etc lic 并命名为hgdb lic,设置权限600和属主highgo:highgo,再启动服务。禁止直接修改data目录下的license info文件。

Oracle BLOB实时同步的5大技术挑战与难点解析
数据库 · 2026-07-25

Oracle BLOB实时同步的5大技术挑战与难点解析

OracleBLOB实时同步面临分片组装、多列隔离、长事务跨窗口、事务回滚及大对象资源控制等技术挑战,必须在日志中精确还原完整字段值,才能保证源端与目标端数据完全一致,这对同步系统的稳健性提出了高要求。

MySQL禁用redo日志导致全备失败
数据库 · 2026-07-25

MySQL禁用redo日志导致全备失败

MySQL全量备份失败是由于数据定义语言操作触发排序索引构建,禁用重做日志导致XtraBackup无法获取一致性备份。测试验证表明,优化表语句即使无数据也会触发该问题。根本原因在于排序索引构建过程跳过了重做日志记录,破坏了备份的一致性。

Kafka架构图优化与改进的全面详细步骤与实践指南
数据库 · 2026-07-25

Kafka架构图优化与改进的全面详细步骤与实践指南

Kafka作为实时数据流处理的核心中间件,其底层架构虽已相当成熟,但在实际生产环境中,要充分发挥其性能潜力,仍需落实到具体的调优与架构改造上。核心目标可归纳为三点:如何承载更高的吞吐量、如何保障数据不丢失、以及故障发生时如何快速恢复。本文将从这几个关键方向出发,深入探讨如何真正榨干Kafka集群的性