2016-01-07 8:12 GMT+01:00 Pavel Stehule <pavel.steh...@gmail.com>: > > > 2016-01-07 1:11 GMT+01:00 Tom Lane <t...@sss.pgh.pa.us>: > >> Dean Rasheed <dean.a.rash...@gmail.com> writes: >> > On 6 January 2016 at 20:09, Robert Haas <robertmh...@gmail.com> wrote: >> >> On Wed, Jan 6, 2016 at 10:21 AM, Dean Rasheed < >> dean.a.rash...@gmail.com> wrote: >> >>> It seems like a useful function to have, but perhaps it should just be >> >>> called trim() rather than numeric_trim(), for consistency with the >> >>> names of the other numeric functions, which don't start with >> >>> "numeric_". >> >> >> That wouldn't work in this case, because we have hard-coded parser >> >> productions for TRIM(). >> >> Does it have to be called TRIM()? After looking at the spec for it >> I'd think rtrim() is the more correct analogy. >> >> Also worth noting is that those hard-wired parser productions aren't >> as hard-wired as all that. >> >> regression=# select trim(43.5); >> ERROR: function pg_catalog.btrim(numeric) does not exist >> >> If we wanted to call the function btrim() underneath, this would >> Just Work. However, to alleviate confusion, it might be better >> if we altered the grammar productions to output "trim" not "btrim" >> for the not-LEADING-or-TRAILING cases, and of course renamed the >> relevant string functions to match. >> >> A different approach is that I'm not real sure why we want a function >> that returns a modified numeric value at all. To the extent I understood >> Marko's original use case, it seems like what you'd invariably do with the >> result is extract its scale(). Why not skip the middleman and define a >> function named something like minscale() or leastscale(), which returns an >> int that is the smallest scale that would not drop data? (If you actually >> did want the modified numeric value, you could use round(x, minscale(x)) >> to get it.) >> > > A example "round(x, minscale(x))" looks nice, but there can be a > performance issues - you have to unpack varlena 2x >
the overhead of two numeric functions instead is about 100ms on 1M rows - that can be acceptable I prefer it over string like design Regards Pavel > > I'll try to some performance tests > > Regards > > Pavel > > >> regards, tom lane >> > >
