Executing type cast functions in postgresql 9.1.3 is not the same as in postgresql 8.2.22. Concatenation is not working correctly

Question

I was using postgresql version 8.2.22, then I upgraded to postgresql 9.1.3 and the upgrade was successfully completed.

But now some casts are not working the same as before!

In Postgres 8.2.22

I run these two queries and they both work correctly:

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)

After upgrade to Postgres 9.1.3

I run the same queries and now they throw errors:

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

Why is it that casting in postgresql is not working as it did before?

Answer 1

Beginning with PostgreSQL 8.3 there are fewer automatic casts. This was changed for two reasons:

1. Many new high-powered types were being introduced, and automatic casting prevented these from being able to use literals in a way that "first-class" types could. Narrowing the cases where the parser tried to guess a data type allowed new types that a user could plug in to be used in a more natural way.

2. Numerous bug reports turned out to be people accidentally getting the "benefit" of automatic casting when they didn't recognize that it was happening, making it hard to find their application coding errors. After 8.3 was released, there were roughly the same number of people posting to say that the change uncovered hidden bugs in their own code as there were people complaining that their code now needed casts where it previously didn't.

It appears that you tried to "solve" this "problem" by adding implicit typecasts. This is a minefield; I don't recommend it. You will limit what features you can safely use and you will have no end of quirky little bugs that nobody else does, and nobody can easily help you with. It is better to fix your code not to assume so many implicit conversions.

One thing which may be confusing you is that in PostgreSQL, '1.2' is not a string literal. It is a literal of unknown type:

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;

I'm arguing it would be cleaner and safer not to add those implicit casts and change the first problem code from:

select TO_NUMBER('12345678',9999999999.99);

to:

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

After all, that second parameter is a format string, not a number. You can't omit the quoting if you want to do something like:

test=# select to_number('12,454.8-', '99G999D9S');
 to_number 
-----------
  -12454.8
(1 row)