Test improvements and minor code fixes for formatting.c.

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

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

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

regards, tom lane

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

Hi,

On Wed, Sep 11, 2024 at 2:33 PM Aleksander Alekseev <
aleksander(at)timescale(dot)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

Aleksander Alekseev <aleksander(at)timescale(dot)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

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

Nathan Bossart <nathandbossart(at)gmail(dot)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