这个问题我之前也踩过坑，核心是Oracle的NUMBER类型和PostgreSQL数值类型的自动映射出了问题——尤其是当Oracle端没指定NUMBER的精度/刻度时，oracle_fdw驱动没法精准匹配PG的类型。下面给你几个可行的解决方案：

方案1：给字段明确指定Oracle类型映射 #

在创建外部表时，给报错的article_id字段添加dbtype选项，强制驱动用Oracle的NUMBER类型做映射。同时建议给ticker字段也明确指定长度，和Oracle端的VARCHAR2(5)保持一致，避免潜在的字符截断问题。

修改后的创建语句如下：

CREATE FOREIGN TABLE latest_article_id (
    ticker VARCHAR(5),
    article_id NUMERIC OPTIONS (dbtype 'NUMBER')
) SERVER usercomm 
OPTIONS ( 
    table '(SELECT article_id, ticker FROM (SELECT a.article_id, t.ticker, ROW_NUMBER() OVER (PARTITION BY t.ticker ORDER BY a.publish_date DESC NULLS LAST) AS rnum FROM tickers t, article_tickers at, articles a WHERE t.ticker_id = at.ticker_id AND at.article_id = a.article_id AND a.status_id = 6 AND a.pull_flag = ''Y'') WHERE rnum = 1)'
);

如果你的article_id实际是整数类型（没有小数部分），可以把PG端的类型换成BIGINT——因为Oracle的NUMBER整数范围比PG的INTEGER（32位）大很多，用BIGINT更安全：

article_id BIGINT OPTIONS (dbtype 'NUMBER')

方案2：检查oracle_fdw版本兼容性 #

确保你用的oracle_fdw驱动版本和PostgreSQL 10.10兼容，建议用oracle_fdw 2.3及以上版本，这个版本对PG10的支持更完善，类型映射逻辑也更准确。

错误原因说明 #

Oracle的NUMBER默认是可变精度（最大38位），而PostgreSQL的NUMERIC虽然也支持高精度，但oracle_fdw自动映射时，若没有明确的类型提示，可能无法识别未指定精度的Oracle NUMBER，导致转换失败。通过dbtype选项直接指定Oracle端的类型，就能让驱动明确该如何做类型转换。

内容的提问来源于stack exchange，提问作者Landon Statis