> On Jun 26, 2026, at 05:35, Masahiko Sawada <[email protected]> wrote:
>
> 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
Thanks for taking care of this patch.
Best regards,
--
Chao Li (Evan)
HighGo Software Co., Ltd.
https://www.highgo.com/
