How to understand to_number formatting in PosgreSQL - sql

Question

I'm not getting behavior that I expect from PostgreSQL's function "to_number" based on my reading of the formatting documentation. So I'm probably reading it wrong. Can someone explain this so that I'll know what to expect in other similar contexts?
-- I find this intuitive:
# select to_number( '12,345.67', '99999.999') ;
to_number
-----------
12345.67
-- I find this surprising:
# select to_number( '12,345.67', '99999.99') ;
to_number
-----------
12345.6
-- EDIT: I found this surprising new variation:
# select to_number( '12,345.67', '999999.99') ;
to_number
-----------
12345.67
Why did my final hundredths digit get dropped in the second case?
EDIT: It seems that the issue is not anything to do with rounding or with how many digits appear to the right of the decimal in my format. Rather, the issue has to do with the total number of characters the format contains and therefore the total number of characters that get parsed. I think the final complete answer will be a slight variation on what mu is too short posted.
In practice I could just always return more digits than I think I need. But that's not very satisfying. It will probably bite me someday. Note: It's not an issue with '9' vs '0' in the format. Those behave identically in to_number, which I find slightly surprising... but clearly documented in the above link.

Answer 1

The problem is that your "number" has a comma as a thousands separator but your pattern does not. Lining them up vertically to make the comparison easier:
12,345.67
99999.99
^
We see that the pattern is looking for a number but it finds a comma. Your pattern doesn't quite match the string you're using so you get unexpected results.
If you add the separator to your pattern (see Table 9.26: Template Patterns for Numeric Formatting in the documentation) then you'll get what you're looking for:
=> select to_number('12,345.67', '99,999.99');
to_number
-----------
12345.67
(1 row)

Answer 2

I will start by thanking mu. His answer was clearly helpful. But I'm posting a separate answer because I think his answer as stated misses an important part of the answer.
I have not looked at any PostgreSQL code, so my answer comes purely from observation of its behavior. When I created my first format, I implicitly assumed something like the following:
# My pseudocode for select to_number( '12,345.67', '99999.99') ;
# I guessed PostgreSQL would do this:
1. Parse up to 5 digits
2. [optionally] find a decimal
3. [optionally] if decimal was found, find up to 2 more digits
in this example:
1. Up to five digits: 12345
2. Decimal: yes
3. Two more digits: 67
4. All together: 12345.67
# But in fact what it does is closer to this:
1. Parse up to 8 characters
2. Find the first decimal point in the parsed characters
3. In the set of parsed characters, find up to 5 characters before the decimal
4. In the set of parsed characters, find up to 2 characters after the decimal.
in this example:
1. Up to 8 characters: 12,345.6
2. First decimal: the penultimate character
3. Before decimal: 12345
4. After decimal: 6
5. All together: 12345.6
Therefore, my problem was fundamentally that PostgreSQL was parsing only 8 characters, but I was passing in 9 characters. Thus the solutions are:
# Mu's suggestion: include comma in the format. Now the format is 9 characters.
# This way it parses all 9 characters:
select to_number('12,345.67', '99,999.99');
to_number
-----------
12345.67
# Or include another character before the decimal
# This way it also parses 9 characters before limiting to 5.2:
select to_number( '12,345.67', '999999.99') ;
to_number
-----------
12345.67
# Or include another character after the decimal
# This way it parses 9 characters before limiting to 5.3:
select to_number( '12,345.67', '99999.999') ;
to_number
-----------
12345.67
And once you look at it like that, it becomes clear why otherwise inscrutable degenerate cases work as they do:
# like this one work as they do:
select to_number('1x2,3yz45.67', '9999999.9999');
to_number
-----------
12345.67
select to_number('12.3.45.67', '9999999.9999');
to_number
-----------
12.3456
I'm not sure that I would have specified the behavior like this. But now it's much clearer what to expect.