Re: Making the ENUM operators LEAKPROOF

On Mon, Jul 20, 2026 at 2:21 PM Laurenz Albe <laurenz(dot)albe(at)cybertec(dot)at>
wrote:
> But enums are important enough for one of our customers that
> they had me look into getting enum comparisons leakproof.
>
> Andreas, do you want to comment?

Hi! Yeah, I help maintain an application that makes extensive use of
ENUM types, including in indexes and composite primary keys. Adopting
row-level security was somewhat of a struggle, as chronicled in [1].

These are the functions whose lack of LEAKPROOFness prevented
predicates from being used as index conditions while row-level security
was active:

* enum_eq(anyenum, anyenum) from enum_ops
* arraycontained(anyarray, anyarray) from gin_array_ops
* arraycontains(anyarray, anyarray) from gin_array_ops
* arrayoverlap(anyarray, anyarray) from gin_array_ops

We eventually found workarounds for all of these issues. The main
reason for posting here, and for involving Laurenz, was to document
our experience and hopefully help others avoid the same pitfalls.

It seemed like getting those functions reviewed and LEAKPROOFed would
be the most straightforward course of action. Zooming out, though,
I hope we can agree that it's worthy goal for these core Postgres
features (RLS, ENUM types, B-tree indexes, and GIN indexes) to compose
well "out of the box" without subtle and potentially severe performance
regressions.

I suggested several other approaches in [1], and I would be willing to
work further on them if there is interest. At the same time, I do not
know enough about the relevant PostgreSQL internals to judge which
direction would make the best long-term design.

My earlier proposal was partly an attempt to nerd-snipe people with
more planner and security-barrier experience into reconsidering the
broader problem. :-)

Does any of you have a good solution in mind?

Best regards,
Andreas Lind

[1]
https://postgr.es/m/CAMxA3rtdJ2OdsPm8pqUKFXh%3DEyB-7Ypyjny%3DZPXoGZEK2nHTKQ%40mail.gmail.com