On Thu, Aug 7, 2025 at 6:44 PM Aleksander Alekseev
<aleksander@tigerdata.com> wrote:
>
> Hi,
>
> > This is a follow-up to b45242fd30ff [1]. Previously we separated
> > varlena.c into varlena.c and bytea.c. This patch makes
> > bytea_sortsupport() independent from varlena.c code as it was proposed
> > before [2][3]. The benefits of this change are summarized in the
> > commit message that I included to the patch.
> >
> > As always, your feedback is most appreciated.
>
> cfbot indicates that v1 needs a rebase. Here is v2.
- * Relies on the assumption that text, VarChar, BpChar, and bytea all have the
- * same representation. Callers that always use the C collation (e.g.
- * non-collatable type callers like bytea) may have NUL bytes in their strings;
- * this will not work with any other collation, though.
+ * Relies on the assumption that text, VarChar, and BpChar all have the
+ * same representation. Callers that use the C collation may have NUL bytes
+ * in their strings; this will not work with any other collation, though.
- * More generally, it's okay that bytea callers can have NUL bytes in
- * strings because abbreviated cmp need not make a distinction between
+ * Generally speaking, it's okay that C locale callers can have NUL bytes
+ * in strings because abbreviated cmp need not make a distinction between
Don't these types disallow NUL bytes regardless of locale / character set?
--
John Naylor
Amazon Web Services
