From e6b71727afc148f90967f4d7ca5cb29891ba2c6c Mon Sep 17 00:00:00 2001 From: Tom Lane Date: Sun, 15 Apr 2018 13:02:12 -0400 Subject: [PATCH] Fix potentially-unportable code in contrib/adminpack. Spelling access(2)'s second argument as "2" is just horrid. POSIX makes no promises as to the numeric values of W_OK and related macros. Even if it accidentally works as intended on every supported platform, it's still unreadable and inconsistent with adjacent code. In passing, don't spell "NULL" as "0" either. Yes, that's legal C; no, it's not project style. Back-patch, just in case the unportability is real and not theoretical. (Most likely, even if a platform had different bit assignments for access()'s modes, there'd not be an observable behavior difference here; but I'm being paranoid today.) --- contrib/adminpack/adminpack.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/contrib/adminpack/adminpack.c b/contrib/adminpack/adminpack.c index 2a532f1a14..a9864ed85e 100644 --- a/contrib/adminpack/adminpack.c +++ b/contrib/adminpack/adminpack.c @@ -173,7 +173,7 @@ pg_file_rename(PG_FUNCTION_ARGS) fn1 = convert_and_check_filename(PG_GETARG_TEXT_P(0), false); fn2 = convert_and_check_filename(PG_GETARG_TEXT_P(1), false); if (PG_ARGISNULL(2)) - fn3 = 0; + fn3 = NULL; else fn3 = convert_and_check_filename(PG_GETARG_TEXT_P(2), false); @@ -195,7 +195,7 @@ pg_file_rename(PG_FUNCTION_ARGS) PG_RETURN_BOOL(false); } - rc = access(fn3 ? fn3 : fn2, 2); + rc = access(fn3 ? fn3 : fn2, W_OK); if (rc >= 0 || errno != ENOENT) { ereport(ERROR, -- 2.50.0