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

Поиск
Список
Период
Сортировка
От Jan Březina
Тема Re: BUG #18219: libpq does not take into consideration UNICODE define
Дата
Msg-id CABODNCxo=+hX9giC1TVW2wGVuMDnC3XungG0a6ymgmTZ9CJ-fQ@mail.gmail.com
обсуждение исходный текст
Ответ на Re: BUG #18219: libpq does not take into consideration UNICODE define  (Tom Lane <tgl@sss.pgh.pa.us>)
Ответы Re: BUG #18219: libpq does not take into consideration UNICODE define  (Thomas Munro <thomas.munro@gmail.com>)
Список pgsql-bugs
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:
and mainly
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@sss.pgh.pa.us> napsal:
Thomas Munro <thomas.munro@gmail.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

В списке pgsql-bugs по дате отправления:

Предыдущее
От: Sergei Kornilov
Дата:
Сообщение: Re:BUG #18221: Unexpected Query Result
Следующее
От: Thomas Munro
Дата:
Сообщение: Re: BUG #18219: libpq does not take into consideration UNICODE define