Re: [PATCH] Add min/max aggregate functions to BYTEA

"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