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  ("Karl O. Pinc" <kop@meme.com>)
Список 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 по дате отправления:

Предыдущее
От: Tom Lane
Дата:
Сообщение: Re: Index corruption / planner issue with one table in my pg 11.6 instance
Следующее
От: Kyotaro Horiguchi
Дата:
Сообщение: Re: [proposal] recovery_target "latest"