Re: Cleaning up historical portability baggage

From: Andres Freund <andres(at)anarazel(dot)de>
To: Thomas Munro <thomas(dot)munro(at)gmail(dot)com>
Cc: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Andrew Dunstan <andrew(at)dunslane(dot)net>, Robert Haas <robertmhaas(at)gmail(dot)com>, pgsql-hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Cleaning up historical portability baggage
Date: 2022-08-06 00:15:18
Message-ID: 20220806001518.4k6uozkkkuorl2da@awork3.anarazel.de
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Hi,

On 2022-08-03 14:25:01 +1200, Thomas Munro wrote:
> It'd be good to find a new home for pg_get_user_name() and
> pg_get_user_home_dir(), which really shouldn't be left in the now
> bogusly named src/port/thread.c. Any suggestions?

Leaving the name aside, the win32 handling of these functions is
embarassing. Both are inside an #ifndef WIN32.

The only caller (in fe-auth.c) of pg_get_user_name() has:
#ifdef WIN32
if (GetUserName(username, &namesize))
name = username;
else if (errorMessage)
appendPQExpBuffer(errorMessage,
libpq_gettext("user name lookup failure: error code %lu\n"),
GetLastError());
#else
if (pg_get_user_name(user_id, pwdbuf, sizeof(pwdbuf)))
name = pwdbuf;
else if (errorMessage)
appendPQExpBuffer(errorMessage, "%s\n", pwdbuf);

the only caller of pg_get_user_home_dir() (path.c) has:

bool
get_home_path(char *ret_path)
{
#ifndef WIN32
/*
* We first consult $HOME. If that's unset, try to get the info from
* <pwd.h>.
*/
const char *home;

home = getenv("HOME");
if (home == NULL || home[0] == '\0')
return pg_get_user_home_dir(geteuid(), ret_path, MAXPGPATH);
strlcpy(ret_path, home, MAXPGPATH);
return true;
#else
char *tmppath;

/*
* Note: We use getenv() here because the more modern SHGetFolderPath()
* would force the backend to link with shell32.lib, which eats valuable
* desktop heap. XXX This function is used only in psql, which already
* brings in shell32 via libpq. Moving this function to its own file
* would keep it out of the backend, freeing it from this concern.
*/
tmppath = getenv("APPDATA");
if (!tmppath)
return false;
snprintf(ret_path, MAXPGPATH, "%s/postgresql", tmppath);
return true;
#endif
}

How does this make any sort of sense?

Greetings,

Andres Freund

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Peter Geoghegan 2022-08-06 00:39:56 Remaining case where reltuples can become distorted across multiple VACUUM operations
Previous Message Andres Freund 2022-08-06 00:03:11 Re: Cleaning up historical portability baggage