"Joel Jacobson" writes:
> On Fri, Dec 4, 2020, at 22:02, Tom Lane wrote:
>> (Maybe the existing ltrim/rtrim descrs are also like this, but if so
>> I'd change them too.)
> They weren't, but I think the description for the bytea functions
> can be improved to have a more precise description
> if w
On Fri, Dec 4, 2020, at 22:02, Tom Lane wrote:
>"trim left ends" (plural) seems wrong. A string only has one left end,
>at least in my universe.
Fixed, the extra "s" came from copying from btrim()'s description.
>(Maybe the existing ltrim/rtrim descrs are also like this, but if so
I>'d change th
"Joel Jacobson" writes:
> On Fri, Dec 4, 2020, at 17:37, Tom Lane wrote:
>> The grammar in the functions' descr strings seems a bit shaky too.
> Not sure what you mean?
"trim left ends" (plural) seems wrong. A string only has one left end,
at least in my universe.
(Maybe the existing ltrim/rtr
On Fri, Dec 4, 2020, at 17:37, Tom Lane wrote:
>No objection in principle, but you need to extend the code added by
>commit 40c24bfef to know about these functions.
Oh, I see, that's a very nice improvement.
I've now added F_LTRIM_BYTEA_BYTEA and F_RTRIM_BYTEA_BYTEA to ruleutils.c
accordingly,
a
"Joel Jacobson" writes:
> The attached patch adds LEADING | TRAILING support for the bytea version of
> trim():
No objection in principle, but you need to extend the code added by
commit 40c24bfef to know about these functions.
The grammar in the functions' descr strings seems a bit shaky too.
Dear hackers,
Let's say we want to strip the leading zero bytes from
'\xbeefbabe00'::bytea.
This is currently not supported, since trim() for bytea values only support the
BOTH mode:
SELECT trim(LEADING '\x00'::bytea FROM '\xbeefbabe00'::bytea);
ERROR: function pg_catalog.ltrim(bytea,
