sql - 在postgresql 9.1.3中执行类型转换功能与在postgresql 8.2.22中不同。串联无法正常工作

Question

我使用的是Postgresql版本8.2.22，然后升级到了Postgresql 9.1.3，并且升级成功完成。

但是现在，某些强制转换与以前不同!

在Postgres 8.2.22中

我运行这两个查询，它们都可以正常工作:

POSTGRES8222=# select TO_NUMBER('12345678',9999999999.99);

to_number
=========   
 12345678
(1 row)

POSTGRES8222=# select a ||'$'|| b from test;
 ?column?
----------
 1$abcdef
 2$ghijkl
 3$3456
(3 rows)

升级到Postgres 9.1.3后

我运行相同的查询，现在它们抛出错误:

select TO_NUMBER('12345678',9999999999.99);

ERROR:  function to_number(unknown, numeric) does not exist
LINE 1: select TO_NUMBER('12345678',9999999999.99);
               ^
HINT:  No function matches the given name and argument types. You might 
need to add explicit type casts.

EXCEPTION
org.postgresql.util.PSQLException: ERROR: function to_number(numeric, numeric) 
does not exist

Hint: No function matches the given name and argument types. You might need 
to add explicit type casts.

Position: 150



select a ||'$'|| b from test;
ERROR:  operator is not unique: numeric || unknown
LINE 1: select a ||'$'|| b from test;
                 ^
HINT:  Could not choose a best candidate operator. You might need to 
add explicit type casts.

********** Error **********
ERROR: operator is not unique: numeric || unknown
SQL state: 42725
Hint: Could not choose a best candidate operator. You might need to  
add explicit type casts.
Character: 10

为什么在postgresql中进行强制转换不能像以前那样工作？

Answer 1

从PostgreSQL 8.3开始，自动转换的数量减少了。之所以被更改，有两个原因:

引入了许多新的高性能类型，并且自动强制转换阻止它们使用“一流”类型可以使用文字的方式。缩小解析器尝试猜测数据类型的情况，可以更自然地使用用户可以插入的新类型。

许多错误报告原来是人们在不认识自动转换的情况下意外地获得了自动转换的“好处”，这使得很难找到他们的应用程序编码错误。在8.3发布之后，大约有相同数量的人说该更改在他们自己的代码中发现了隐藏的错误，就像有些人提示他们的代码现在需要在以前不需要的地方进行强制转换一样。

看来您试图通过添加隐式类型转换来“解决”此“问题”。这是一个雷区；我不推荐。您将限制可以安全使用的功能，并且没有其他人会做的古怪的小错误，并且没有人可以轻松地为您提供帮助。最好修复您的代码，使其不承担太多的隐式转换。

可能使您感到困惑的一件事是，在PostgreSQL中， '1.2'不是字符串文字。它是未知类型的文字:

test=# select pg_typeof('1.2'); pg_typeof ----------- unknown(1 row)

PostgreSQL holds off on resolving the type of a literal as long as it can, which works great with all those new data types I was describing. As a last resort, if the time comes when it has to resolve the type and there are no other clues, it treats it as type text.

test=# select pg_typeof(case when true then '1.2' else null end); pg_typeof ----------- text(1 row)test=# select pg_typeof(case when true then '1.2' else 2.3 end); pg_typeof ----------- numeric(1 row)

Problem 2, "aftertypecast", is failing because with all the implicit type casts you added, there is more than one possible operator || which could be chosen depending on which implicit typecasts it performed, and there was no principled way to choose among them. If you change that line to the following, it should work again:

select a || '$'::text || b from test;

我认为不添加那些隐式强制类型转换并从以下方式更改第一个问题代码会更安全，更安全:

select TO_NUMBER('12345678',9999999999.99);

至:

select TO_NUMBER('12345678', '9999999999.99');

毕竟，第二个参数是格式字符串，而不是数字。如果要执行以下操作，则不能省略引号:

test =＃选择to_number('12，454.8-'，'99G999D9S');
to_number
-----------
-12454.8
(1列)