Re: BUG #18219: libpq does not take into consideration UNICODE define

The project is not misconfigured. Windows applications use MBCS (multi byte
character set) or UNICODE defines to specify what Windows API they are
using and there are good reasons not to mix the two.
You should read the following documentation:
https://learn.microsoft.com/en-us/windows/win32/intl/unicode-in-the-windows-api
and mainly
https://learn.microsoft.com/en-us/windows/win32/intl/conventions-for-function-prototypes
So if you are not planning to support UNICODE define, then you should be
concrete in what Windows API you are using and call the **A (ANSI) API
directly, as I suggested. It is a correct way, doesn't conflict with any
defines and doesn't conflict with any standard API, as UNICODE define
affects only the behavior of Windows API.
I bet there won't be so much work to fix this, as Windows specific
implementations are in separate *win32.c files and hence it should not
affect any other platforms and it has to work with every compiler, as it is
the standard Windows API.
I'm surprised no one raised this problem up until now and I believe there
must be a lot of workarounds to make libpq library work "correctly".
If the patch would be accepted, I can help with it's implementation.

Dne čt 30. 11. 2023 23:32 uživatel Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> napsal:

> Thomas Munro <thomas(dot)munro(at)gmail(dot)com> writes:
> >> Seems like a non-starter.
>
> > ... and I should probably explain why. This project has difficulty
> > maintaining Windows support, because of a general lack of PostgreSQL
> > developers working on that platform (but we welcome more! patches
> > welcome!) and a disproportionately high amount of maintenance work
> > that it generates. One factor is that there are several different
> > Windows configurations (different compilers, C runtimes, build
> > systems, file system semantics, partial POSIX emulations like MSYS and
> > Cygwin...) to consider. I doubt we'd want to add another dimension to
> > that problem space by saying we have to maintain and test the UNICODE
> > and non-UNICODE code paths in our libraries.
>
> Yeah, I think there's no chance that we'd accept such a patch even if
> one were submitted. Quite aside from the initial development effort,
> the ongoing maintenance cost would be large, and the value is just not
> there (as evidenced by the approximately zero previous requests we've
> had for this).
>
> > Hence my intuition that we should be figuring out where the right
> > place is to suppress or undefine UNICODE.
>
> I'm not even excited about that. Would we accept patches to #undef
> the random other system-API-changing symbols that exist on other
> platforms? We've not done so in the past and I don't see a great
> argument to start here. IMO the submitter has simply misconfigured
> his project. He should not assume that he can build other peoples'
> code with whatever configuration suits his own code.
>
> regards, tom lane
>