Re: Potential security risk associated with function call

From: Daniel Gustafsson <daniel(at)yesql(dot)se>
To: Jet <zhangchenxi(at)halodbtech(dot)com>
Cc: Robert Haas <robertmhaas(at)gmail(dot)com>, Matthias van de Meent <boekewurm+postgres(at)gmail(dot)com>, PostgreSQL Hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Potential security risk associated with function call
Date: 2026-03-10 13:13:24
Message-ID: A04093C8-3E0B-46D3-ADA5-D8CE52ECAC31@yesql.se
Views: Whole Thread | Raw Message | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

> On 10 Mar 2026, at 14:09, Jet <zhangchenxi(at)halodbtech(dot)com> wrote:
>
>> but the 2026 reality is that someone would
>> just say "deploy an AI agent to check whether the code is safe for the
>> definition," and that might actually work in practical cases, but
>> we're not going to add a call-out to Claude as part of the CREATE
>> FUNCTION statement.
> I notice the potential problem just because using Claude to write a simple
> extension. And it works well on testing enviroment. But when take over the
> Claude generated extenion to dev enviroment, the server crashed.
> More and more people will use AI to generate codes, that's the trend, but AI
> will make mistakes, and may leave many potention risks. So I suppose as the
> base platform, we should try our best efforts to make it more robust.

There is no protection strong enough against developers who run generated C
code in production that they didn't read, review and test properly.

--
Daniel Gustafsson

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Xuneng Zhou 2026-03-10 13:23:26 Re: Streamify more code paths
Previous Message Daniel Gustafsson 2026-03-10 13:11:00 Re: Serverside SNI support in libpq