On Wed, Jun 24, 2026 at 11:30 AM Masahiko Sawada <sawada.mshk@gmail.com> wrote:
>
> Hi,
>
> On Sun, Jun 21, 2026 at 9:00 PM Chao Li <li.evan.chao@gmail.com> wrote:
> >
> > Hi,
> >
> > While testing "[ba21f5bf8] Allow explicit casting between bytea and uuid", I noticed that the new proc bytea(uuid)
isnot marked as proleakproof, while the other functions in the group, bytea(int2), bytea(int4), and bytea(int8), are
allmarked 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
notto mark bytea(uuid) as proleakproof.
> >
> > This matters for security barrier planning, because a qual using uuid::bytea is otherwise treated as leaky and
cannotbe 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
inpg_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
