parse_address function screws up when zip is > 5 characters

[robe]

Originally when I first came across this with a Canadian address, I blamed Canada, but then I noticed a lot of my normal_address ones (which pass with tiger normalize address, fail when using pagc_normalize_address). On closer inspection it seems the address_standardizer parse_address function is to blame.

See how state doesn't fill in and city has state

test_tiger=# SELECT (each(hstore(a))).* FROM parse_address('212 3rd Ave N, MINNEAPOLIS, MN 553404') As a;
   key    |           value
----------+----------------------------
 num      | 212
 zip      |
 city     | MN 553404
 state    |
 street   | 3rd Ave N, MINNEAPOLIS
 country  | US
 street2  |
 zipplus  |
 address1 | 212 3rd Ave N, MINNEAPOLIS
(9 rows)

now if I do this:

SELECT (each(hstore(a))).* 
FROM parse_address('212 3rd Ave N, MINNEAPOLIS, MN 55401') As a;
   key    |     value
----------+---------------
 num      | 212
 zip      | 55401
 city     | MINNEAPOLIS
 state    | MN
 street   | 3rd Ave N
 country  | US
 street2  |
 zipplus  |
 address1 | 212 3rd Ave N
(9 rows)

works fine

this requires muddling with C code, so might need woodbri for this one.

[robe]

Fixed at r13992

Hopefully I didn't break anything fixing this. The only regress that failed (was one that had the issue I raised and now it shows the right answer). All other tests still work as expected.

and this now returns right answer:

SELECT (each(hstore(a))).* FROM parse_address('212 3rd Ave N, MINNEAPOLIS, MN 553404') As a;
   key    |     value
----------+---------------
 num      | 212
 zip      | 55340
 city     | MINNEAPOLIS
 state    | MN
 street   | 3rd Ave N
 country  | US
 street2  |
 zipplus  | 4
 address1 | 212 3rd Ave N
(9 rows)