Horton

Thread

Commits

  1. Add bytea equivalents of ltrim() and rtrim().

  2. Improve our ability to regurgitate SQL-syntax function calls.

  1. [PATCH] Add support for leading/trailing bytea trim()ing

    Joel Jacobson <joel@compiler.org> — 2020-12-04T16:30:43Z

    Dear hackers,

Let's say we want to strip the leading zero bytes from '\x0000beefbabe00'::bytea.

This is currently not supported, since trim() for bytea values only support the BOTH mode:

SELECT trim(LEADING '\x00'::bytea FROM '\x0000beefbabe00'::bytea);
ERROR:  function pg_catalog.ltrim(bytea, bytea) does not exist

The attached patch adds LEADING | TRAILING support for the bytea version of trim():

SELECT trim(LEADING '\x00'::bytea FROM '\x0000beefbabe00'::bytea);
    ltrim
--------------
\xbeefbabe00

SELECT trim(TRAILING '\x00'::bytea FROM '\x0000beefbabe00'::bytea);
     rtrim
----------------
\x0000beefbabe

Best regards,

Joel Jacobson

  2. Re: [PATCH] Add support for leading/trailing bytea trim()ing

    Tom Lane <tgl@sss.pgh.pa.us> — 2020-12-04T16:37:38Z

    "Joel Jacobson" <joel@compiler.org> 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.

			regards, tom lane

  3. Re: [PATCH] Add support for leading/trailing bytea trim()ing

    Joel Jacobson <joel@compiler.org> — 2020-12-04T18:44:37Z

    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,
and also added regress tests to create_view.sql.

>The grammar in the functions' descr strings seems a bit shaky too.

Not sure what you mean? The grammar is unchanged, since it was already supported,
but the overloaded bytea functions were missing.

I did however notice I forgot to update the description in func.sgml
for the bytea version of trim(). Maybe that's what you meant was shaky?
I've changed the description to read:

-        <parameter>bytesremoved</parameter> from the start
-        and end of <parameter>bytes</parameter>.
+        <parameter>bytesremoved</parameter> from the start,
+        the end, or both ends of <parameter>bytes</parameter>.
+        (<literal>BOTH</literal> is the default)

New patch attached.

/Joel

  4. Re: [PATCH] Add support for leading/trailing bytea trim()ing

    Tom Lane <tgl@sss.pgh.pa.us> — 2020-12-04T21:02:12Z

    "Joel Jacobson" <joel@compiler.org> 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/rtrim descrs are also like this, but if so
I'd change them too.)

			regards, tom lane

  5. Re: [PATCH] Add support for leading/trailing bytea trim()ing

    Joel Jacobson <joel@compiler.org> — 2020-12-05T07:22:13Z

    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 them too.)

They weren't, but I think the description for the bytea functions
can be improved to have a more precise description
if we take inspiration from the the text functions.

Here is an overview of all functions containing "trim" in the function name,
to get the full picture of the trim description terminology:

SELECT
  oid,
  pg_describe_object('pg_proc'::regclass,oid,0),
  pg_catalog.obj_description(oid, 'pg_proc')
FROM pg_proc
WHERE proname LIKE '%trim%'
ORDER BY oid;

oid  |      pg_describe_object      |                     obj_description
------+------------------------------+----------------------------------------------------------
  875 | function ltrim(text,text)    | trim selected characters from left end of string
  876 | function rtrim(text,text)    | trim selected characters from right end of string
  881 | function ltrim(text)         | trim spaces from left end of string
  882 | function rtrim(text)         | trim spaces from right end of string
  884 | function btrim(text,text)    | trim selected characters from both ends of string
  885 | function btrim(text)         | trim spaces from both ends of string
2015 | function btrim(bytea,bytea)  | trim both ends of string
5043 | function trim_scale(numeric) | numeric with minimum scale needed to represent the value

Do we want the two new functions to derive their description from the existing bytea function?

9612 | function ltrim(bytea,bytea)  | trim left end of string
9613 | function rtrim(bytea,bytea)  | trim right end of string

Patch with this wording: leading-trailing-trim-bytea-left-right-end-of-string.patch

Or would it be better to be inspired by the more precise descriptions for the two parameter text functions,
and to change the existing btrim() function's description as well?

2015 | function btrim(bytea,bytea)  | trim selected bytes from both ends of string
9612 | function ltrim(bytea,bytea)  | trim selected bytes from left end of string
9613 | function rtrim(bytea,bytea)  | trim selected bytes from right end of string

Patch with this wording: leading-trailing-trim-bytea-selected-bytes.patch

Best regards,

Joel

  6. Re: [PATCH] Add support for leading/trailing bytea trim()ing

    Tom Lane <tgl@sss.pgh.pa.us> — 2021-01-18T20:13:42Z

    "Joel Jacobson" <joel@compiler.org> 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 we take inspiration from the the text functions.

Yeah, I agree with making the bytea descriptions look like the
text ones.  Pushed with minor additional doc fixes.

			regards, tom lane