Skip to content
Snippets Groups Projects
Commit 65f2e868 authored by Tom Lane's avatar Tom Lane
Browse files

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.)
parent 131f6a95
No related branches found
No related tags found
No related merge requests found
...@@ -173,7 +173,7 @@ pg_file_rename(PG_FUNCTION_ARGS) ...@@ -173,7 +173,7 @@ pg_file_rename(PG_FUNCTION_ARGS)
fn1 = convert_and_check_filename(PG_GETARG_TEXT_P(0), false); fn1 = convert_and_check_filename(PG_GETARG_TEXT_P(0), false);
fn2 = convert_and_check_filename(PG_GETARG_TEXT_P(1), false); fn2 = convert_and_check_filename(PG_GETARG_TEXT_P(1), false);
if (PG_ARGISNULL(2)) if (PG_ARGISNULL(2))
fn3 = 0; fn3 = NULL;
else else
fn3 = convert_and_check_filename(PG_GETARG_TEXT_P(2), false); fn3 = convert_and_check_filename(PG_GETARG_TEXT_P(2), false);
...@@ -195,7 +195,7 @@ pg_file_rename(PG_FUNCTION_ARGS) ...@@ -195,7 +195,7 @@ pg_file_rename(PG_FUNCTION_ARGS)
PG_RETURN_BOOL(false); PG_RETURN_BOOL(false);
} }
rc = access(fn3 ? fn3 : fn2, 2); rc = access(fn3 ? fn3 : fn2, W_OK);
if (rc >= 0 || errno != ENOENT) if (rc >= 0 || errno != ENOENT)
{ {
ereport(ERROR, ereport(ERROR,
......
0% Loading or .
You are about to add 0 people to the discussion. Proceed with caution.
Please register or to comment