Re: Potential security risk associated with function call

From: Jet <zhangchenxi(at)halodbtech(dot)com>
To: Robert Haas <robertmhaas(at)gmail(dot)com>, Kirill Reshke <reshkekirill(at)gmail(dot)com>
Cc: Matthias van de Meent <boekewurm+postgres(at)gmail(dot)com>, pgsql-hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Potential security risk associated with function call
Date: 2026-03-10 14:05:01
Message-ID: tencent_37918D9635645707762384FD@qq.com
Views: Whole Thread | Raw Message | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

> Right, but in case they don't, instead of writing their own CREATE
> FUNCTION statements, they might want to use CREATE EXTENSION, thus
> depending on the wisdom of the extension provider in lieu of their
> own.
>
> In ~30 years as a PostgreSQL user and developer, I've only written a
> relatively small number of CREATE FUNCTION ... LANGUAGE c/internal
> statements myself, and they've all been either for an extension or for
> some kind of development exercise. There's no real reason to go around
> writing random such statements that are completely broken just for
> fun.
I don't think it just for fun. People may prefer to use EXTENSION, but the
problem is may the EXTENSION was written by a person who don't have full
skills with extension developing or even without any code experience but only
using AI. Just in the case I notice the problem. AI doing all the things and on
most cases it works well but leave potential risks. Will the end user really to
study the whole EXTENSION code? I can ensure most of them will not. And AI
will take over to do the most of coding works, that iss what happening...

Regards,
Jet
Halo Tech

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Amit Khandekar 2026-03-10 14:07:10 Re: Inconsistency in owner assignment between INDEX and STATISTICS
Previous Message Fujii Masao 2026-03-10 13:57:18 Re: brin: Remove duplicate initialization in initialize_brin_buildstate()