| From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
|---|---|
| To: | maciek(at)sakrejda(dot)org |
| Cc: | Hunaid Sohail <hunaidpgml(at)gmail(dot)com>, pgsql-hackers(at)lists(dot)postgresql(dot)org, Tomas Vondra <tomas(at)vondra(dot)me> |
| Subject: | Re: [PATCH] Add roman support for to_number function |
| Date: | 2025-01-21 01:41:25 |
| Message-ID: | 3256645.1737423685@sss.pgh.pa.us |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
Maciek Sakrejda <m(dot)sakrejda(at)gmail(dot)com> writes:
> V7 passes check-world here. But, just for kicks, I generated all
> possible 7-character sequences of Roman digits [1] to confirm whether
> everything either parsed cleanly or errored cleanly. Reviewing the
> output, I noticed that to_number accepts some dubiously-formatted
> values:
> postgres=# select to_number('mmmdcm', 'RN');
> to_number
> -----------
> 4400
> (1 row)
Ugh. This makes more urgent my question about where roman_to_int's
algorithm came from, because there's evidently something not right
about it.
regards, tom lane
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Tom Lane | 2025-01-21 01:44:07 | Re: Add RESPECT/IGNORE NULLS and FROM FIRST/LAST options |
| Previous Message | Jeremy Schneider | 2025-01-21 01:25:54 | Re: New feature request for adding session information to PostgreSQL transaction log |