[PATCH] Add min/max aggregate functions to BYTEA

Hello. BYTEA type has the ability to use comparison operations. But it
is absent of min/max aggregate functions. They are nice to have to
provide consistency with the TEXT type.

--

With best regards,
Marat Bukharov

V2 patch with fixed tests

--

With best regards,
Marat Bukharov

ср, 3 июл. 2024 г. в 16:03, Marat Buharov <marat(dot)buharov(at)gmail(dot)com>:
>
> Hello. BYTEA type has the ability to use comparison operations. But it
> is absent of min/max aggregate functions. They are nice to have to
> provide consistency with the TEXT type.
>
>
> --
>
> With best regards,
> Marat Bukharov

V3 patch with fixed length comparison

--

With best regards,
Marat Bukharov

>
> V2 patch with fixed tests
>
> >
> > Hello. BYTEA type has the ability to use comparison operations. But it
> > is absent of min/max aggregate functions. They are nice to have to
> > provide consistency with the TEXT type.
> >

V3 patch with fixed length comparison

--

With best regards,
Marat Bukharov

>
> V2 patch with fixed tests
>
> >
> > Hello. BYTEA type has the ability to use comparison operations. But it
> > is absent of min/max aggregate functions. They are nice to have to
> > provide consistency with the TEXT type.
> >

V4 path with fixed usage PG_GETARG_BYTEA_PP instead of PG_GETARG_TEXT_PP

--

With best regards,
Marat Bukharov

>
> V3 patch with fixed length comparison
>
> >
> > V2 patch with fixed tests
> >
> > >
> > > Hello. BYTEA type has the ability to use comparison operations. But it
> > > is absent of min/max aggregate functions. They are nice to have to
> > > provide consistency with the TEXT type.
> > >

Hi Marat,

> V4 path with fixed usage PG_GETARG_BYTEA_PP instead of PG_GETARG_TEXT_PP

Thanks for the patch.

Please add it to the nearest open commitfest [1].

```
+select min(v) from bytea_test_table;
+ min
+------
+ \xaa
+(1 row)
+
+select max(v) from bytea_test_table;
+ max
+------
+ \xff
+(1 row)
```

If I understand correctly, all the v's are of the same size. If this
is the case you should add more test cases.

[1]: https://commitfest.postgresql.org/

--
Best regards,
Aleksander Alekseev

What part of commitfest should I put the current patch to: "SQL
Commands", "Miscellaneous" or something else? I can't figure it out.

--

With best regards,
Marat Bukharov

> Hi Marat,
>
> > V4 path with fixed usage PG_GETARG_BYTEA_PP instead of PG_GETARG_TEXT_PP
>
> Thanks for the patch.
>
> Please add it to the nearest open commitfest [1].
>
> ```
> +select min(v) from bytea_test_table;
> + min
> +------
> + \xaa
> +(1 row)
> +
> +select max(v) from bytea_test_table;
> + max
> +------
> + \xff
> +(1 row)
> ```
>
> If I understand correctly, all the v's are of the same size. If this
> is the case you should add more test cases.
>
> [1]: https://commitfest.postgresql.org/
>
> --
> Best regards,
> Aleksander Alekseev

Hi,

> What part of commitfest should I put the current patch to: "SQL
> Commands", "Miscellaneous" or something else? I can't figure it out.

Personally I qualified a similar patch [1] as "Server Features",
although I'm not 100% sure if this was the best choice.

[1]: https://commitfest.postgresql.org/48/4905/

--
Best regards,
Aleksander Alekseev

V5 patch. I've added more tests with different bytea sizes

--

With best regards,
Marat Bukharov

чт, 4 июл. 2024 г. в 15:29, Aleksander Alekseev <aleksander(at)timescale(dot)com>:
>
> Hi Marat,
>
> > V4 path with fixed usage PG_GETARG_BYTEA_PP instead of PG_GETARG_TEXT_PP
>
> Thanks for the patch.
>
> Please add it to the nearest open commitfest [1].
>
> ```
> +select min(v) from bytea_test_table;
> + min
> +------
> + \xaa
> +(1 row)
> +
> +select max(v) from bytea_test_table;
> + max
> +------
> + \xff
> +(1 row)
> ```
>
> If I understand correctly, all the v's are of the same size. If this
> is the case you should add more test cases.
>
> [1]: https://commitfest.postgresql.org/
>
> --
> Best regards,
> Aleksander Alekseev

Added patch to commitfest https://commitfest.postgresql.org/49/5138/

--

With best regards,
Marat Bukharov

>
> Hi,
>
> > What part of commitfest should I put the current patch to: "SQL
> > Commands", "Miscellaneous" or something else? I can't figure it out.
>
> Personally I qualified a similar patch [1] as "Server Features",
> although I'm not 100% sure if this was the best choice.
>
> [1]: https://commitfest.postgresql.org/48/4905/
>
> --
> Best regards,
> Aleksander Alekseev

> On 24 Jul 2024, at 17:42, Marat Bukharov <marat(dot)buharov(at)gmail(dot)com> wrote:
>
> V5 patch. I've added more tests with different bytea sizes

Hi Marat!

This looks like a nice feature to have.

I’ve took a look into the patch and have few suggestions:
0. Please write more descriptive commit message akin to [0]
1. Use oids from development range 8000-9999
2. Replace VARDATA_ANY\memcmp dance with a call to varstrfastcmp_c().

Thank you!

Best regards, Andrey Borodin.

[0] https://github.com/postgres/postgres/commit/a0f1fce80c03

"Andrey M. Borodin" <x4mmm(at)yandex-team(dot)ru> writes:
> 0. Please write more descriptive commit message akin to [0]
> 1. Use oids from development range 8000-9999

Yeah, we don't try anymore to manually select permanent oids [1].

> 2. Replace VARDATA_ANY\memcmp dance with a call to varstrfastcmp_c().

I don't agree with that recommendation in the slightest: it's a
fundamental type pun for bytea to piggyback on text/varchar functions.
It risks bugs in bytea due to somebody inserting collation dependencies
into those functions. It also creates special cases that those
functions shouldn't have to cope with, see e.g. comment for
varstr_sortsupport about how we have to allow NUL bytes there but
only if it's C locale. That's a laughably rickety bit of coding.

I see that somebody already made such a pun in bytea_sortsupport,
but that was a bad idea that we should undo not double down on.

I wonder if we shouldn't pull all the bytea support functions out
of varlena.c (say into a new file bytea.c), to discourage such
gamesmanship in the future.

regards, tom lane

[1] https://www.postgresql.org/docs/devel/system-catalog-initial-data.html#SYSTEM-CATALOG-OID-ASSIGNMENT

On Thu, 25 Jul 2024 at 02:42, Marat Bukharov <marat(dot)buharov(at)gmail(dot)com> wrote:
> V5 patch. I've added more tests with different bytea sizes

I just glanced over this patch. Are you still planning on working on
it? There's been no adjustments made since the last feedback you got
in early August.

Can you address Andrey's feedback on point #1?

Also, for bytea_larger() and bytea_smaller(), I suggest copying what's
been done in record_larger() and record_smaller() except use
byteacmp(). That'll remove all the duplicated code.

If you fix those up, I see no reason not to commit the patch.

David

Hi,

> I just glanced over this patch. Are you still planning on working on
> it? There's been no adjustments made since the last feedback you got
> in early August.
>
> Can you address Andrey's feedback on point #1?
>
> Also, for bytea_larger() and bytea_smaller(), I suggest copying what's
> been done in record_larger() and record_smaller() except use
> byteacmp(). That'll remove all the duplicated code.
>
> If you fix those up, I see no reason not to commit the patch.

Since we haven't heard from Marat since July I decided to rebase the
patch and address the feedback received so far. PFA patch v6.

--
Best regards,
Aleksander Alekseev

> On 8 Oct 2024, at 19:23, Aleksander Alekseev <aleksander(at)timescale(dot)com> wrote:
>
> PFA patch v6.

IMO the patch looks RfC.

Best regards, Andrey Borodin.

"Andrey M. Borodin" <x4mmm(at)yandex-team(dot)ru> writes:
> IMO the patch looks RfC.

LGTM too. Pushed.

regards, tom lane

Thank you for the corrections. I was busy recently and did not follow
conversations in the mailing list. Sorry about that.

--

With best regards,
Marat Bukharov

вт, 8 окт. 2024 г. в 17:24, Aleksander Alekseev <aleksander(at)timescale(dot)com>:
>
> Hi,
>
> > I just glanced over this patch. Are you still planning on working on
> > it? There's been no adjustments made since the last feedback you got
> > in early August.
> >
> > Can you address Andrey's feedback on point #1?
> >
> > Also, for bytea_larger() and bytea_smaller(), I suggest copying what's
> > been done in record_larger() and record_smaller() except use
> > byteacmp(). That'll remove all the duplicated code.
> >
> > If you fix those up, I see no reason not to commit the patch.
>
> Since we haven't heard from Marat since July I decided to rebase the
> patch and address the feedback received so far. PFA patch v6.
>
> --
> Best regards,
> Aleksander Alekseev