Horton

Thread

Commits

  1. Modernize to_char's Roman-numeral code, fixing overflow problems.

  1. Test improvements and minor code fixes for formatting.c.

    Tom Lane <tgl@sss.pgh.pa.us> — 2024-09-08T21:32:16Z

    Over in the thread about teaching to_number() to handle Roman
numerals [1], it was noted that we currently have precisely zero
test coverage for to_char()'s existing Roman-numeral code, except
in the timestamp code path which shares nothing with the numeric
code path.

In looking at this, I found that there's also no test coverage
for the EEEE, V, or PL format codes.  Also, the possibility of
overflow while converting an input value to int in order to
pass it to int_to_roman was ignored.  Attached is a patch that
adds more test coverage and cleans up the Roman-numeral code
a little bit.

BTW, I also discovered that there is a little bit of support
for a "B" format code: we can parse it, but then we ignore it.
And it's not documented.  Oracle defines this code as a flag
that:

	Returns blanks for the integer part of a fixed-point number
	when the integer part is zero (regardless of zeros in the
	format model).

It doesn't seem super hard to implement that, but given the
complete lack of complaints about it being missing, maybe we
should just rip out the incomplete support instead?

			regards, tom lane

[1] https://www.postgresql.org/message-id/flat/CAMWA6ybh4M1VQqpmnu2tfSwO%2B3gAPeA8YKnMHVADeB%3DXDEvT_A%40mail.gmail.com

  2. Re: Test improvements and minor code fixes for formatting.c.

    Tom Lane <tgl@sss.pgh.pa.us> — 2024-09-08T22:39:50Z

    I wrote:
> [ v1-formatting-test-improvements.patch ]

Meh ... cfbot points out I did the float-to-int conversions wrong.
v2 attached.

			regards, tom lane

  3. Re: Test improvements and minor code fixes for formatting.c.

    Aleksander Alekseev <aleksander@timescale.com> — 2024-09-11T09:32:50Z

    Hi Tom,

> Meh ... cfbot points out I did the float-to-int conversions wrong.
> v2 attached.

I'm having difficulties applying the patch. Could you please do `git
format-patch` and resend it?

-- 
Best regards,
Aleksander Alekseev

  4. Re: Test improvements and minor code fixes for formatting.c.

    Hunaid Sohail <hunaidpgml@gmail.com> — 2024-09-11T11:29:52Z

    Hi,

On Wed, Sep 11, 2024 at 2:33 PM Aleksander Alekseev <
aleksander@timescale.com> wrote:

> I'm having difficulties applying the patch. Could you please do `git
> format-patch` and resend it?
>

Yes, I guess there is some issue with the patch but somehow I was able to
apply it.

make installcheck-world -> tested, passed
Documentation -> tested, passed

Regards,
Hunaid Sohail

  5. Re: Test improvements and minor code fixes for formatting.c.

    Tom Lane <tgl@sss.pgh.pa.us> — 2024-09-11T14:01:09Z

    Aleksander Alekseev <aleksander@timescale.com> writes:
> I'm having difficulties applying the patch. Could you please do `git
> format-patch` and resend it?

patch(1) is generally far more forgiving than 'git am'.

			regards, tom lane

  6. Re: Test improvements and minor code fixes for formatting.c.

    Nathan Bossart <nathandbossart@gmail.com> — 2024-09-17T21:59:37Z

    On Sun, Sep 08, 2024 at 05:32:16PM -0400, Tom Lane wrote:
> In looking at this, I found that there's also no test coverage
> for the EEEE, V, or PL format codes.  Also, the possibility of
> overflow while converting an input value to int in order to
> pass it to int_to_roman was ignored.  Attached is a patch that
> adds more test coverage and cleans up the Roman-numeral code
> a little bit.

I stared at the patch for a while, and it looks good to me.

> BTW, I also discovered that there is a little bit of support
> for a "B" format code: we can parse it, but then we ignore it.
> And it's not documented.  Oracle defines this code as a flag
> that:
> 
> 	Returns blanks for the integer part of a fixed-point number
> 	when the integer part is zero (regardless of zeros in the
> 	format model).
> 
> It doesn't seem super hard to implement that, but given the
> complete lack of complaints about it being missing, maybe we
> should just rip out the incomplete support instead?

AFAICT it's been like that since it was introduced [0].  I searched the
archives and couldn't find any discussion about this format code.  Given
that, I don't have any concerns about removing it unless it causes ERRORs
for calls that currently succeed, but even then, it's probably fine.  This
strikes me as something that might be fun for an aspiring hacker, though.

[0] https://postgr.es/c/b866d2e

-- 
nathan

  7. Re: Test improvements and minor code fixes for formatting.c.

    Tom Lane <tgl@sss.pgh.pa.us> — 2024-09-26T15:04:33Z

    Nathan Bossart <nathandbossart@gmail.com> writes:
> On Sun, Sep 08, 2024 at 05:32:16PM -0400, Tom Lane wrote:
>> In looking at this, I found that there's also no test coverage
>> for the EEEE, V, or PL format codes.  Also, the possibility of
>> overflow while converting an input value to int in order to
>> pass it to int_to_roman was ignored.  Attached is a patch that
>> adds more test coverage and cleans up the Roman-numeral code
>> a little bit.

> I stared at the patch for a while, and it looks good to me.

Pushed, thanks for looking!

>> BTW, I also discovered that there is a little bit of support
>> for a "B" format code: we can parse it, but then we ignore it.

> AFAICT it's been like that since it was introduced [0].  I searched the
> archives and couldn't find any discussion about this format code.  Given
> that, I don't have any concerns about removing it unless it causes ERRORs
> for calls that currently succeed, but even then, it's probably fine.  This
> strikes me as something that might be fun for an aspiring hacker, though.

Yeah, I left that alone for now.  I don't have much interest in
making it work, but perhaps someone else will.

			regards, tom lane