[PATCH] Add roman support for to_number function

From: Hunaid Sohail <hunaidpgml(at)gmail(dot)com>
To: pgsql-hackers(at)postgresql(dot)org
Subject: [PATCH] Add roman support for to_number function
Date: 2024-08-30 07:21:52
Message-ID: CAMWA6ybh4M1VQqpmnu2tfSwO+3gAPeA8YKnMHVADeB=XDEvT_A@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Hi,

While looking at formatting.c file, I noticed a TODO about "add support for
roman number to standard number conversion" (
https://github.com/postgres/postgres/blob/master/src/backend/utils/adt/formatting.c#L52
)

I have attached the patch that adds support for this and converts roman
numerals to standard numbers (1 to 3999) while also checking if roman
numerals are valid or not.
I have also added a new error code: ERRCODE_INVALID_ROMAN_NUMERAL in case
of invalid numerals.

A few examples:

postgres=# SELECT to_number('MC', 'RN');
to_number
-----------
1100
(1 row)

postgres=# SELECT to_number('XIV', 'RN');
to_number
-----------
14
(1 row)

postgres=# SELECT to_number('MMMCMXCIX', 'RN');
to_number
-----------
3999
(1 row)

postgres=# SELECT to_number('MCCD', 'RN');
ERROR: invalid roman numeral

I would appreciate your feedback on the following cases:
- Is it okay for the function to handle Roman numerals in a
case-insensitive way? (e.g., 'XIV', 'xiv', and 'Xiv' are all seen as 14).
- How should we handle Roman numerals with leading or trailing spaces, like
' XIV' or 'MC '? Should we trim the spaces, or would it be better to throw
an error in such cases?

I have tested the changes and would appreciate any suggestions for
improvement. I will update the docs and regressions in the next version of
patch.

Regards,
Hunaid Sohail

Attachment Content-Type Size
v1-0001-Add-RN-rn-support-for-to_number-function.patch application/octet-stream 5.8 KB

Browse pgsql-hackers by date

  From Date Subject
Next Message Peter Eisentraut 2024-08-30 07:27:05 Re: consider -Wmissing-variable-declarations
Previous Message Amit Kapila 2024-08-30 06:57:57 Re: Conflict Detection and Resolution