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 I'll try to some performance tests Regards Pavel > regards, tom lane >
