Re: proposal: minscale, rtrim, btrim functions for numeric
От | Pavel Stehule |
---|---|
Тема | Re: proposal: minscale, rtrim, btrim functions for numeric |
Дата | |
Msg-id | CAFj8pRCLHSe6wLE7K7AsVC5aOyhv+4S7Er+xxFyivd2DoEdEGw@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: proposal: minscale, rtrim, btrim functions for numeric ("Karl O. Pinc" <kop@meme.com>) |
Ответы |
Re: proposal: minscale, rtrim, btrim functions for numeric
|
Список | pgsql-hackers |
út 10. 12. 2019 v 0:03 odesílatel Karl O. Pinc <kop@meme.com> napsal:
On Mon, 9 Dec 2019 21:04:21 +0100
Pavel Stehule <pavel.stehule@gmail.com> wrote:
> I fixed almost all mentioned issues (that I understand)
If you don't understand you might ask, or at least say.
That way I know you've noticed my remarks and I don't
have to repeat them.
I have 2 remaining suggestions.
1) As previously suggested: Consider moving
all the code you added to numeric.c to right after
the scale() related code. This is equivalent to
what was done in pg_proc.dat and regression tests
where all the scale related stuff is in one
place in the file.
2) Now that the function is called min_scale()
it might be nice if your "minscale" variable
in numeric.c was named "min_scale".
I don't feel particularly strongly about either
of the above but think them a slight improvement.
done
I also wonder whether all the trim_scale() tests
are now necessary, but not enough to make any suggestions.
Especially because, well, tests are good.
I don't think so tests should be minimalistic - there can be some redundancy to coverage some less probable size effects of some future changes. More - there is a small symmetry with min_scale tests - and third argument - some times I use tests (result part) as "documentation". But I have not any problem to reduce tests if there will be requirement to do it.
Regards
Pavel
Regards,
Karl <kop@meme.com>
Free Software: "You don't pay back, you pay forward."
-- Robert A. Heinlein
Вложения
В списке pgsql-hackers по дате отправления: