why in appendShellStringNoError() loop still continues even after it found CR or LF?
./psql postgres
postgres=# BEGIN;
Hi,
i have naive doubt $SUBJECT,AFAIK The reasoning would be this function is
designed to silently filter out \n and \r while still producing a usable
shell-safe argument. It informs the caller of the issue (false return
value) but does not abruptly stop execution,then the caller will decide
what to do but every place this function is called they are just throwing
the error.
if theres no proper reason to loop and continue we can use strpbrk and
return false when we found \n or \r.
thoughts?
May the force be with you,
Srinath Reddy Sadipiralla
EDB: https://www.enterprisedb.com/
postgres=*# COMMIT;
postgres=# \q
On Sat, Mar 29, 2025 at 8:37 AM Srinath Reddy <srinath2133@gmail.com> wrote:
i have naive doubt $SUBJECT,AFAIK The reasoning would be this function is designed to silently filter out \n and \r while still producing a usable shell-safe argument. It informs the caller of the issue (false return value) but does not abruptly stop execution,then the caller will decide what to do but every place this function is called they are just throwing the error.
That is true, but one of the two call sites exits the program, and the
other does not, so the cases are different.
if theres no proper reason to loop and continue we can use strpbrk and return false when we found \n or \r.
I don't know what you mean by this. There are comments within
appendShellStringNoError and atop appendShellString which explain the
intended behavior, and the function seems to correctly implement that
behavior in a pretty straightforward way. While it's probably true
that someone could have chosen to use strpbrk, I don't see any real
advantage to that over the way it was actually done.
Returning as soon as an \r or \n is found would change the documented
behavior, so one couldn't make that change without carefully
considering the implications for the callers.
--
Robert Haas
EDB: http://www.enterprisedb.com