[PATCH] Add min/max aggregate functions to BYTEA

V2 patch with fixed tests

--

With best regards,
Marat Bukharov

ср, 3 июл. 2024 г. в 16:03, Marat Buharov <marat.buharov@gmail.com>:

V3 patch with fixed length comparison

--

With best regards,
Marat Bukharov

V3 patch with fixed length comparison

--

With best regards,
Marat Bukharov

V4 path with fixed usage PG_GETARG_BYTEA_PP instead of PG_GETARG_TEXT_PP

--

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]https://commitfest.postgresql.org/.

```
+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,

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]https://commitfest.postgresql.org/48/4905/ 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@timescale.com>:

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

--

With best regards,
Marat Bukharov

On 24 Jul 2024, at 17:42, Marat Bukharov <marat.buharov@gmail.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]https://github.com/postgres/postgres/commit/a0f1fce80c03
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@yandex-team.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]https://www.postgresql.org/docs/devel/system-catalog-initial-data.html#SYSTEM-CATALOG-OID-ASSIGNMENT.

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.buharov@gmail.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@timescale.com> wrote:

PFA patch v6.

IMO the patch looks RfC.

Best regards, Andrey Borodin.

"Andrey M. Borodin" <x4mmm@yandex-team.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@timescale.com>: