Re: [PATCH] Add min/max aggregate functions to BYTEA - Mailing list pgsql-hackers

From Tom Lane
Subject Re: [PATCH] Add min/max aggregate functions to BYTEA
Date
Msg-id 1502394.1725398354@sss.pgh.pa.us
Whole thread Raw
In response to Re: [PATCH] Add min/max aggregate functions to BYTEA  ("Andrey M. Borodin" <x4mmm@yandex-team.ru>)
List pgsql-hackers
"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



pgsql-hackers by date:

Previous
From: Nathan Bossart
Date:
Subject: Re: Pgstattuple on Sequences: Seeking Community Feedback on Potential Patch
Next
From: Noah Misch
Date:
Subject: Re: race condition in pg_class