On Wed, Jun 24, 2026 at 11:30 AM Masahiko Sawada <[email protected]> wrote: > > Hi, > > On Sun, Jun 21, 2026 at 9:00 PM Chao Li <[email protected]> wrote: > > > > Hi, > > > > While testing "[ba21f5bf8] Allow explicit casting between bytea and uuid", > > I noticed that the new proc bytea(uuid) is not marked as proleakproof, > > while the other functions in the group, bytea(int2), bytea(int4), and > > bytea(int8), are all marked as proleakproof. > > > > Looking into the backend function uuid_bytea(), it just returns > > uuid_send(fcinfo). For a valid uuid datum, uuid_send() only copies the UUID > > value into a bytea result, so I don't see an input-dependent error path or > > other reason not to mark bytea(uuid) as proleakproof. > > > > This matters for security barrier planning, because a qual using > > uuid::bytea is otherwise treated as leaky and cannot be pushed down. > > Attached is a tiny patch to fix that. > > > > I didn't mark uuid_send() itself as proleakproof because none of > > send/receive functions are marked as proleakproof in pg_proc.dat. > > Thank you for the report. > > I agree that we should mark bytea(uuid) (i.e., converting uuid -> > bytea) as leakproof but not the opposite direction. > > The patch is simple and looks good to me. I'll push the patch, barring > any objections.
Pushed, and resolved the open item. Regards, -- Masahiko Sawada Amazon Web Services: https://aws.amazon.com
