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.)

diff --git a/contrib/adminpack/adminpack.c b/contrib/adminpack/adminpack.c
index 2a532f1a14008488b3193c5c38e381ac2329ceb4..a9864ed85e3370a973445e1e4d1995fbc107d6c4 100644 (file)
--- 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,