On Mon, Nov 03, 2025 at 09:15:25PM -0800, Joshua Shanks wrote:
> Thank you for the detailed feedback! This is my first C project
> contribution, so I really appreciate you taking the time to explain the
> proper error handling pattern.
No problem. Applied on HEAD after a few tweaks:
* two libpq_g
On Mon, Nov 3, 2025 at 2:35 AM Michael Paquier wrote:
> The point would be to have pqConnectOptions2() take its oom_error path
> in the case you are pointing at. It seems to me that the correct
> answer would be to extend passwordFromFile() with an extra "const char
> **errmsg", where an error i
On Sun, Nov 02, 2025 at 09:09:55AM +0900, Michael Paquier wrote:
> Sounds OK to me. Nice catch. It's probably not worth bothering in
> the stable branches as the error is unlikely going to show up.
And, while checking the surroundings, I have noticed that your patch
is incomplete: passwordFromFi
On Sat, Nov 01, 2025 at 04:49:02PM -0700, Joshua Shanks wrote:
> The conn parameter is placed first, consistent with the object-oriented
> convention used throughout libpq (see connectOptions1,
> fillPGconn, store_conn_addrinfo, etc.).
Sounds OK to me. Nice catch. It's probably not worth botheri
Hi,
I noticed a XXX comment in fe-connect.c at line 8064 indicating that
an error message would be nice when strdup() fails while reading the
password file. Currently, passwordFromFile() silently returns NULL on
allocation failure, leaving users without feedback on what went wrong.
This patch add
