Date: Tue, 17 Sep 2024 16:59:37 -0500
From: Nathan Bossart <nathandbossart@gmail.com>
To: Tom Lane <tgl@sss.pgh.pa.us>
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.
Message-ID: <Zun7yZP4AL8gVLEH@nathan>
References: <2956175.1725831136@sss.pgh.pa.us>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <2956175.1725831136@sss.pgh.pa.us>
Archived-At: <https://www.postgresql.org/message-id/Zun7yZP4AL8gVLEH%40nathan>
Precedence: bulk

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