From: Tom Lane <tgl@sss.pgh.pa.us>
To: Nathan Bossart <nathandbossart@gmail.com>
cc: pgsql-hackers@lists.postgresql.org,
 Maciek Sakrejda <m.sakrejda@gmail.com>,
        Hunaid Sohail <hunaidpgml@gmail.com>
Subject: Re: Test improvements and minor code fixes for formatting.c.
In-reply-to: <Zun7yZP4AL8gVLEH@nathan>
References: <2956175.1725831136@sss.pgh.pa.us> <Zun7yZP4AL8gVLEH@nathan>
Comments: In-reply-to Nathan Bossart <nathandbossart@gmail.com>
	message dated "Tue, 17 Sep 2024 16:59:37 -0500"
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-ID: <320334.1727363073.1@sss.pgh.pa.us>
Date: Thu, 26 Sep 2024 11:04:33 -0400
Message-ID: <320335.1727363073@sss.pgh.pa.us>
Archived-At: 
 <https://www.postgresql.org/message-id/320335.1727363073%40sss.pgh.pa.us>
Precedence: bulk

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