Dean Rasheed <dean.a.rasheed@gmail.com> writes: > On 6 January 2016 at 20:09, Robert Haas <robertmhaas@gmail.com> wrote: >> On Wed, Jan 6, 2016 at 10:21 AM, Dean Rasheed <dean.a.rasheed@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
