On Wed, Sep 28, 2022 at 10:10 AM Michael Paquier <mich...@paquier.xyz> wrote: > > One important thing, in my opinion, when it comes to updating this > table, is that it could be better to report the original error number > if errno can be somewhat confusing for the mapping.
Returning errno = e instead of EINVAL in _dosmaperr() may have an impact on the callers that do a special handling for errno EINVAL. I don't think it's a good idea. > ERROR_INVALID_NAME => ENOENT > Yeah, this mapping looks fine. Hm. > ERROR_HANDLE_DISK_FULL => ENOSPC > This one maps to various Setup*Error(), as well as > GetDiskFreeSpaceEx(). The former is not interesting, but I can buy > the case of the former for extension code (I've played with that in > the past on WIN32, actually). > > ERROR_OUTOFMEMORY => ENOMEM > ERROR_NOACCESS => EACCES > ERROR_INSUFFICIENT_BUFFER => EINVAL > Hmm. I have looked at our WIN32 system calls and the upstream docs, > but these do not seem to be reachable in our code. IMO, we can add mapping for just ERROR_INVALID_NAME which is an obvious error code and easy to hit, leaving others. There are actually many win32 error codes that may get hit in our code base and actually mapping everything isn't possible. Please see the v2 patch. I've also added a CF entry - https://commitfest.postgresql.org/40/3914/ so that the patch gets tested across. -- Bharath Rupireddy PostgreSQL Contributors Team RDS Open Source Databases Amazon Web Services: https://aws.amazon.com
v2-0001-Extend-win32-error-codes-to-errno-mapping-in-win3.patch
Description: Binary data
