Re: [PATCH v1] Replace sprintf() with snprintf() in libpq for safety Anexo: o arquivo

From: "David G(dot) Johnston" <david(dot)g(dot)johnston(at)gmail(dot)com>
To: Álvaro Herrera <alvherre(at)kurilemu(dot)de>
Cc: Thiago Caserta <caserta(at)movestax(dot)com>, "pgsql-hackers(at)postgresql(dot)org" <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: [PATCH v1] Replace sprintf() with snprintf() in libpq for safety Anexo: o arquivo
Date: 2026-03-26 23:54:12
Message-ID: CAKFQuwY5RcdcgCbCRBC5g0k9sbNspNbtyRgWAJBJhkb_pfX1RA@mail.gmail.com
Views: Whole Thread | Raw Message | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Thu, Mar 26, 2026 at 4:33 PM Álvaro Herrera <alvherre(at)kurilemu(dot)de> wrote:

> On 2026-Mar-24, Thiago Caserta wrote:
>
> > Attached is a patch that converts several sprintf() calls to
> > snprintf() in libpq client library code.
>
> I'm not sure we should take a patch with a tag attributing authorship to
> an LLM owned by a commercial entity.

Agreed. As with a book author, any bad code, decisions, or other mistakes
are solely the fault of the submitting author. As is the good stuff.
Ideally the author has confirmed it is good (in their own opinion) since
they expect others to do so as well as part of the review and commit
process.

It is in fact a reputational thing for authors to take full ownership of
what they submit.

> Do we really want to be accepting code patches written by tools that
> make the most obvious code worse than before? I am quite scared of the
> quality of code of medium complexity written by this tool.
>
>
I'd say take this as an opportunity to teach (or not) just as if the author
of patch claimed to write the entire thing without AI assistance. But it
would definitely be reasonable for a hastily produced patch that doesn't
pass muster to be hastily rejected on such grounds. We have plenty to
review and if this patch wouldn't have existed without LLM assistance then
unless it sparks the interest in someone to go and clean it up anyway we
are not really any worse off being quick to state that it doesn't meet our
standards.

Otherwise, while there is a patch, maybe just treat it as a simple
suggestion with an example.

David J.

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Bharath Rupireddy 2026-03-27 00:10:41 Re: log XLogPrefetch stats at end of recovery
Previous Message Masahiko Sawada 2026-03-26 23:51:14 Re: Initial COPY of Logical Replication is too slow