Thread: [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
Attachment
V2 patch with fixed tests -- With best regards, Marat Bukharov ср, 3 июл. 2024 г. в 16:03, Marat Buharov <marat.buharov@gmail.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
Attachment
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. > >
Attachment
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. > > >
Attachment
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@timescale.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
Attachment
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.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] 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].
> 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
> 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>: > > 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