On Mon, Jul 20, 2026 at 2:21 PM Laurenz Albe <[email protected]> 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
