Re: A micro-optimisation for walkdir()

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Thomas Munro <thomas(dot)munro(at)gmail(dot)com>
Cc: Juan José Santamaría Flecha <juanjo(dot)santamaria(at)gmail(dot)com>, pgsql-hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: A micro-optimisation for walkdir()
Date: 2020-09-03 15:31:40
Message-ID: 596203.1599147100@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Thomas Munro <thomas(dot)munro(at)gmail(dot)com> writes:
> On Thu, Sep 3, 2020 at 5:36 PM Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
>> Both of these concerns would abate if we had get_dirent_type()
>> just throw an error itself when stat() fails, thereby removing the
>> PGFILETYPE_ERROR result code. I'm not 100% sold either way on
>> that, but it's something to think about. Is there ever going
>> to be a reason for the caller to ignore an error?

> Hmm. Well I had it like that in an earlier version, but then I
> couldn't figure out the right way to write code that would work in
> both frontend and backend code, without writing two copies in two
> translation units, or putting the whole thing in a header. What
> approach do you prefer?

Well, there are plenty of places in src/port/ where we do things like

#ifndef FRONTEND
ereport(ERROR,
(errcode_for_file_access(),
errmsg("could not get junction for \"%s\": %s",
path, msg)));
#else
fprintf(stderr, _("could not get junction for \"%s\": %s\n"),
path, msg);
#endif

I don't see a compelling reason why this function couldn't report
stat() failures similarly, especially if we're just going to have
the callers do exactly the same thing as that anyway.

regards, tom lane

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Dagfinn Ilmari Mannsåker 2020-09-03 15:40:28 Re: [PATCH] Missing links between system catalog documentation pages
Previous Message Dave Page 2020-09-03 15:15:03 Re: Kerberos support broken on MSVC builds for Windows x64?