Re: funcs.sgml - wrong example
От | Kyotaro Horiguchi |
---|---|
Тема | Re: funcs.sgml - wrong example |
Дата | |
Msg-id | 20220518.111931.2195791660070768858.horikyota.ntt@gmail.com обсуждение исходный текст |
Ответ на | Re: funcs.sgml - wrong example (Kyotaro Horiguchi <horikyota.ntt@gmail.com>) |
Список | pgsql-hackers |
At Wed, 18 May 2022 11:11:02 +0900 (JST), Kyotaro Horiguchi <horikyota.ntt@gmail.com> wrote in > At Wed, 18 May 2022 03:08:32 +0200, Erik Rijkers <er@xs4all.nl> wrote in > > funcs.sgml has > > > > 42 <@ '{[1,7)}'::int4multirange > > > > and calls it true. The attached fixes that. > > > > Included are two more changes where actual output differs a bit from > > what the doc examples show. Forgot to mention, the all changes look good. The log(b,n) has 16 trailing digits at least since 9.6. > A bit off-topic and just out of curiocity, is there a reason other > than speed (and history?) for that we won't truncate trailing zeros in > the output of log(b,n)? Hmm. A bit wrong. I meant that, if we can allow some additional cycles and we don't stick to the past behavior of the function, we could have a nicer result. > Since we have get_min_scale since 13, for example, with the following > tweak, we get 6.0 for log(2.0, 64.0), which looks nicer. > > > @@ -10300,6 +10300,8 @@ log_var(const NumericVar *base, const NumericVar *num, NumericVar *result) > /* Divide and round to the required scale */ > div_var_fast(&ln_num, &ln_base, result, rscale, true); > > + result->dscale = Max(get_min_scale(result), base->dscale); > + result->dscale = Max(result->dscale, num->dscale); > free_var(&ln_num); -- Kyotaro Horiguchi NTT Open Source Software Center
В списке pgsql-hackers по дате отправления: