Re: PG compilation error with Visual Studio 2015/2017/2019

From: davinder singh <davindersingh2692(at)gmail(dot)com>
To: Juan José Santamaría Flecha <juanjo(dot)santamaria(at)gmail(dot)com>
Cc: Pg Hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: PG compilation error with Visual Studio 2015/2017/2019
Date: 2020-04-09 08:25:22
Message-ID: CAHzhFSE4EA4K0U5ht5L=kA2=gfy=YjyaECp2ghC0y1_3uUzkMA@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Wed, Apr 8, 2020 at 7:39 PM Juan José Santamaría Flecha

> Let me explain further, in pg_config_os.h you can check that the value of
> _WIN32_WINNT is solely based on checking _MSC_VER. This patch should also
> be meaningful for WIN32 builds using MinGW, or we might see this issue
> reappear in those systems if update the MIN_WINNT value to more current
> OS versions. So, I still think _WIN32_WINNT is a better option.
>
Thanks for explanation, I was not aware of that, you are right it make
sense to use " _WIN32_WINNT", Now I am using this only.

I still see the same last lines in both #ifdef blocks, and pgindent might
> change a couple of lines to:
> + MultiByteToWideChar(CP_ACP, 0, winlocname, -1, wc_locale_name,
> + LOCALE_NAME_MAX_LENGTH);
> +
> + if ((GetLocaleInfoEx(wc_locale_name, LOCALE_SNAME,
> + (LPWSTR)&buffer, LOCALE_NAME_MAX_LENGTH)) > 0)
> + {
>
Now I have resolved these comments also, Please check updated version of
the patch.

> Please open an item in the commitfest for this patch.
>
I have created with same title.

--
Regards,
Davinder
EnterpriseDB: http://www.enterprisedb.com

Attachment Content-Type Size
0001-PG-compilation-error-with-VS-2015-2017-2019.patch application/octet-stream 3.7 KB

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Justin Pryzby 2020-04-09 08:33:19 Re: Vacuum o/p with (full 1, parallel 0) option throwing an error
Previous Message Masahiko Sawada 2020-04-09 08:07:48 Re: Vacuum o/p with (full 1, parallel 0) option throwing an error