On Thu, May 14, 2020 at 11:07 AM Ranier Vilela wrote:
> Em qui., 14 de mai. de 2020 às 05:49, Amit Kapila
> escreveu:
>
>> On Wed, May 13, 2020 at 7:34 PM Tom Lane wrote:
>> >
>> > Amit Kapila writes:
>> > > Now that branches are tagged, I would like to commit and backpatch
>> > > this patch t
Em qui., 14 de mai. de 2020 às 05:49, Amit Kapila
escreveu:
> On Wed, May 13, 2020 at 7:34 PM Tom Lane wrote:
> >
> > Amit Kapila writes:
> > > Now that branches are tagged, I would like to commit and backpatch
> > > this patch tomorrow unless there are any more comments/objections.
> >
> > The
On Wed, May 13, 2020 at 7:34 PM Tom Lane wrote:
>
> Amit Kapila writes:
> > Now that branches are tagged, I would like to commit and backpatch
> > this patch tomorrow unless there are any more comments/objections.
>
> The "quiet period" is over as soon as the tags appear in git.
>
Pushed.
--
W
Amit Kapila writes:
> Now that branches are tagged, I would like to commit and backpatch
> this patch tomorrow unless there are any more comments/objections.
The "quiet period" is over as soon as the tags appear in git.
regards, tom lane
On Thu, May 7, 2020 at 6:51 PM Tom Lane wrote:
>
> Amit Kapila writes:
> > On Thu, May 7, 2020 at 11:57 AM Tom Lane wrote:
> >> Monday is a back-branch release wrap day.
>
> > How can I get the information about release wrap day? The minor
> > release dates are mentioned on the website [1], but
Amit Kapila writes:
> On Thu, May 7, 2020 at 11:57 AM Tom Lane wrote:
>> Monday is a back-branch release wrap day.
> How can I get the information about release wrap day? The minor
> release dates are mentioned on the website [1], but this information
> is not available. Do we keep it some-fix
On Thu, May 7, 2020 at 11:57 AM Tom Lane wrote:
>
> Amit Kapila writes:
> > Thanks, Juan and Davinder for verifying the latest patches. I think
> > this patch is ready to commit unless someone else has any comments. I
> > will commit and backpatch this early next week (probably on Monday)
> > un
On Thu, May 7, 2020 at 11:57 AM Tom Lane wrote:
>
> Amit Kapila writes:
> > Thanks, Juan and Davinder for verifying the latest patches. I think
> > this patch is ready to commit unless someone else has any comments. I
> > will commit and backpatch this early next week (probably on Monday)
> > un
Amit Kapila writes:
> Thanks, Juan and Davinder for verifying the latest patches. I think
> this patch is ready to commit unless someone else has any comments. I
> will commit and backpatch this early next week (probably on Monday)
> unless I see more comments.
Monday is a back-branch release wr
On Wed, May 6, 2020 at 11:01 PM Juan José Santamaría Flecha
wrote:
>
> On Wed, May 6, 2020 at 6:41 AM Amit Kapila wrote:
>>
>> On Wed, May 6, 2020 at 4:19 AM Juan José Santamaría Flecha
>> >
>> > I think that the definition of get_iso_localename() should be consistent
>> > across all versions, t
On Wed, May 6, 2020 at 10:11 AM Amit Kapila wrote:
>
> > I think that the definition of get_iso_localename() should be consistent
> across all versions, that is HEAD like back-patched.
> >
>
> Fair enough. I have changed such that get_iso_localename is the same
> in HEAD as it is backbranch patc
On Wed, May 6, 2020 at 6:41 AM Amit Kapila wrote:
> On Wed, May 6, 2020 at 4:19 AM Juan José Santamaría Flecha
> >
> > I think that the definition of get_iso_localename() should be consistent
> across all versions, that is HEAD like back-patched.
> >
>
> Fair enough. I have changed such that get
On Wed, May 6, 2020 at 4:19 AM Juan José Santamaría Flecha
wrote:
>
> On Tue, May 5, 2020 at 1:34 PM Amit Kapila wrote:
>>
>>
>> Apart from that, I have made a few other changes in comments, fixed
>> typos, and ran pgindent. Let me know what do you think of attached
>> patches?
>
>
> The patches
On Tue, May 5, 2020 at 1:34 PM Amit Kapila wrote:
>
> Apart from that, I have made a few other changes in comments, fixed
> typos, and ran pgindent. Let me know what do you think of attached
> patches?
>
The patches are definitely in better shape.
I think that the definition of get_iso_localen
On Mon, May 4, 2020 at 6:59 PM Juan José Santamaría Flecha
wrote:
>
> On Thu, Apr 30, 2020 at 5:07 AM Amit Kapila wrote:
>>
>>
>> Okay, thanks. The key point to keep in mind is to avoid touching the
>> code related to prior MSVC versions as we might not have set up to
>> test those.
>
>
> Please
On Thu, Apr 30, 2020 at 5:07 AM Amit Kapila wrote:
> >
> > I was not aware of how many switches IsoLocaleName() already had before
> trying to backpatch. I think offering an alternative might be a cleaner
> approach, I will work on that.
> >
>
> Okay, thanks. The key point to keep in mind is to
On Wed, Apr 29, 2020 at 9:36 PM Juan José Santamaría Flecha
wrote:
>
> On Wed, Apr 29, 2020 at 3:50 PM Amit Kapila wrote:
>>
>> On Wed, Apr 29, 2020 at 5:57 PM Amit Kapila wrote:
>> >
>> > 2. I think the code in IsoLocaleName is quite confusing and difficult
>> > to understand in back branches a
On Wed, Apr 29, 2020 at 3:50 PM Amit Kapila wrote:
> On Wed, Apr 29, 2020 at 5:57 PM Amit Kapila
> wrote:
> >
> > 2. I think the code in IsoLocaleName is quite confusing and difficult
> > to understand in back branches and the changes due to this bug-fix
> > made it more complicated. I am think
On Wed, Apr 29, 2020 at 5:57 PM Amit Kapila wrote:
>
>
> 2. I think the code in IsoLocaleName is quite confusing and difficult
> to understand in back branches and the changes due to this bug-fix
> made it more complicated. I am thinking to refactor it such that the
> code for (_MSC_VER >= 1700 &
On Mon, Apr 27, 2020 at 4:50 PM Amit Kapila wrote:
>
> I think we should backpatch this till 9.5 as I could see the changes
> made by commit 0fb54de9 to support MSVC2015 are present in that branch
> and the same is mentioned in the commit message.
>
Today, I was thinking about the pros and cons o
On Tue, Apr 28, 2020 at 11:39 PM Juan José Santamaría Flecha
wrote:
>
>
> On Mon, Apr 27, 2020 at 1:20 PM Amit Kapila wrote:
>>
>> I think we should backpatch this till 9.5 as I could see the changes
>> made by commit 0fb54de9 to support MSVC2015 are present in that branch
>> and the same is ment
On Tue, Apr 28, 2020 at 11:45 PM Juan José Santamaría Flecha <
juanjo.santama...@gmail.com> wrote:
>
> On Tue, Apr 28, 2020 at 5:16 PM davinder singh <
> davindersingh2...@gmail.com> wrote:
>
>> I have tested with different locales with codepages including above.
>> There are few which return diff
On Wed, Apr 29, 2020 at 8:24 AM Amit Kapila wrote:
> BTW, do you see any different results for pt_PT with create_locale
> version or the new patch version being discussed here?
>
No, there is no difference for pt_PT. The difference you are noticing is
because of the previous locale setting.
--
On Wed, Apr 29, 2020 at 8:21 AM Amit Kapila wrote:
>
> On Wed, Apr 29, 2020 at 1:32 AM Ranier Vilela wrote:
> >
> > Em ter., 28 de abr. de 2020 às 16:53, Juan José Santamaría Flecha
> > escreveu:
> >>
> >>
> >>
> >> On Tue, Apr 28, 2020 at 9:38 PM Ranier Vilela wrote:
> >>>
> >>> "pt" means po
On Wed, Apr 29, 2020 at 1:32 AM Ranier Vilela wrote:
>
> Em ter., 28 de abr. de 2020 às 16:53, Juan José Santamaría Flecha
> escreveu:
>>
>>
>>
>> On Tue, Apr 28, 2020 at 9:38 PM Ranier Vilela wrote:
>>>
>>> "pt" means portuguese language.
>>> "pt_BR" means portuguese language from Brazil, "div
On Tue, Apr 28, 2020 at 9:38 PM Ranier Vilela wrote:
> "pt" means portuguese language.
> "pt_BR" means portuguese language from Brazil, "divisão por zero", is
> correct.
> "pt_PT" means portuguese language from Portugal, "division by zero"?
> poderia ser "divisão por zero", too.
>
> Why "pt_PT" d
On Tue, Apr 28, 2020 at 5:16 PM davinder singh
wrote:
> On Mon, Apr 27, 2020 at 4:50 PM Amit Kapila
> wrote:
>
>> Bemba_Zambia
>> Bena_Tanzania
>> Bulgarian_Bulgaria
>> Swedish_Sweden.1252
>> Swedish_Sweden
>>
>
> I have tested with different locales with codepages including above. There
> are f
On Mon, Apr 27, 2020 at 1:20 PM Amit Kapila wrote:
> I think we should backpatch this till 9.5 as I could see the changes
> made by commit 0fb54de9 to support MSVC2015 are present in that branch
> and the same is mentioned in the commit message. Would you like to
> prepare patches (and test thos
On Mon, Apr 27, 2020 at 4:50 PM Amit Kapila wrote:
> Bemba_Zambia
> Bena_Tanzania
> Bulgarian_Bulgaria
> Swedish_Sweden.1252
> Swedish_Sweden
>
I have tested with different locales with codepages including above. There
are few which return different locale code but the error messages in both
the
On Thu, Apr 23, 2020 at 6:30 PM Amit Kapila wrote:
>
> On Thu, Apr 23, 2020 at 5:37 PM Juan José Santamaría Flecha
> wrote:
> >
> > I have composed a small set of queries to test the output with different
> > lc_message settings (lc_messages_test.sql). Please find attached the output
> > from d
On Fri, Apr 24, 2020 at 7:47 AM davinder singh
wrote:
> On Thu, Apr 23, 2020 at 6:49 PM Juan José Santamaría Flecha <
> juanjo.santama...@gmail.com> wrote:
>
>> On Thu, Apr 23, 2020 at 3:00 PM Amit Kapila
>> wrote:
>>
>>>
>>> Thanks, I will verify these. BTW, have you done something special to
On Thu, Apr 23, 2020 at 6:49 PM Juan José Santamaría Flecha <
juanjo.santama...@gmail.com> wrote:
>
> On Thu, Apr 23, 2020 at 3:00 PM Amit Kapila
> wrote:
>
>>
>> Thanks, I will verify these. BTW, have you done something special to
>> get the error messages which are not in English because on my
On Thu, Apr 23, 2020 at 3:00 PM Amit Kapila wrote:
>
> Thanks, I will verify these. BTW, have you done something special to
> get the error messages which are not in English because on my Windows
> box I am not getting that in spite of setting it to the appropriate
> locale. Did you use ICU or
On Thu, Apr 23, 2020 at 5:37 PM Juan José Santamaría Flecha
wrote:
>
>
> On Thu, Apr 23, 2020 at 5:30 AM Amit Kapila wrote:
>>
>>
>> I think we can check with simple error messages. So, basically after
>> setting a particular value of LC_MESSAGES, execute a query which
>> returns syntax or any o
On Thu, Apr 23, 2020 at 5:30 AM Amit Kapila wrote:
>
> Okay, I hope we will see better comments in the next version.
>
I have focused on improving comments in this version.
> Hmm, if you really want to log the value then do it in the caller. I
> don't think making special arrangements just fo
On Wed, Apr 22, 2020 at 9:27 PM Juan José Santamaría Flecha
wrote:
>
>
> On Wed, Apr 22, 2020 at 1:43 PM Amit Kapila wrote:
>>
>>
>> >> 4. In the patch, first, we try to get with LCType as LOCALE_SNAME and
>> >> then with LOCALE_SENGLISHLANGUAGENAME and LOCALE_SENGLISHCOUNTRYNAME.
>> >> I think w
On Wed, Apr 22, 2020 at 7:37 PM Ranier Vilela wrote:
>
> Em qua., 22 de abr. de 2020 às 08:43, Amit Kapila
> escreveu:
>>
>> On Tue, Apr 21, 2020 at 5:32 PM Juan José Santamaría Flecha
>> wrote:
>> >
>> > On Tue, Apr 21, 2020 at 12:41 PM Amit Kapila
>> > wrote:
>> >>
>>
>> 6. I have additiona
On Wed, Apr 22, 2020 at 1:43 PM Amit Kapila wrote:
> On Tue, Apr 21, 2020 at 5:32 PM Juan José Santamaría Flecha
> wrote:
> >
> > I cannot reproduce any of these errors on my end.
> >
> The first problem related to the English_United Kingdom was due to the
> usage of wcslen instead of pg_mbstrle
Em qua., 22 de abr. de 2020 às 08:43, Amit Kapila
escreveu:
> On Tue, Apr 21, 2020 at 5:32 PM Juan José Santamaría Flecha
> wrote:
> >
> > On Tue, Apr 21, 2020 at 12:41 PM Amit Kapila
> wrote:
> >>
>
6. I have additionally done some cosmetic changes in the attached patch.
>
I made some style ch
On Tue, Apr 21, 2020 at 5:32 PM Juan José Santamaría Flecha
wrote:
>
> On Tue, Apr 21, 2020 at 12:41 PM Amit Kapila wrote:
>>
>> On Tue, Apr 21, 2020 at 12:51 PM Amit Kapila wrote:
>> >
>> > I have tried a simple test with the latest patch and it failed for me.
>> >
>> > Set LC_MESSAGES="English
On Tue, Apr 21, 2020 at 2:22 PM Ranier Vilela wrote:
> More few comments.
>
> 1. Comments about order:
> /*
> * Callback function for EnumSystemLocalesEx.
> * Stop enumerating if a match is found for a locale with the format
> * _.
> * The order for search locale is essential:
> * Find LCTyp
Em ter., 21 de abr. de 2020 às 09:02, Juan José Santamaría Flecha <
juanjo.santama...@gmail.com> escreveu:
>
> On Tue, Apr 21, 2020 at 12:41 PM Amit Kapila
> wrote:
>
>> On Tue, Apr 21, 2020 at 12:51 PM Amit Kapila
>> wrote:
>> >
>> > I have tried a simple test with the latest patch and it faile
On Tue, Apr 21, 2020 at 12:41 PM Amit Kapila
wrote:
> On Tue, Apr 21, 2020 at 12:51 PM Amit Kapila
> wrote:
> >
> > I have tried a simple test with the latest patch and it failed for me.
> >
> > Set LC_MESSAGES="English_United Kingdom";
> > -- returns en-GB, then code changes it to en_NZ when _c
On Tue, Apr 21, 2020 at 12:51 PM Amit Kapila wrote:
>
> On Mon, Apr 20, 2020 at 6:32 PM Amit Kapila wrote:
> >
> > On Sun, Apr 19, 2020 at 3:46 PM Juan José Santamaría Flecha
> > wrote:
> > >
> > > I cannot find a single place where all supported locales are listed, but
> > > I have created a s
On Mon, Apr 20, 2020 at 6:32 PM Amit Kapila wrote:
>
> On Sun, Apr 19, 2020 at 3:46 PM Juan José Santamaría Flecha
> wrote:
> >
> > I cannot find a single place where all supported locales are listed, but I
> > have created a small test program (WindowsNLSLocales.c) based on:
> > [_] format loc
On Sun, Apr 19, 2020 at 3:46 PM Juan José Santamaría Flecha
wrote:
>
>
> On Sat, Apr 18, 2020 at 6:07 AM Amit Kapila wrote:
>>
>> On Sat, Apr 18, 2020 at 12:14 AM Juan José Santamaría Flecha
>> wrote:
>> >
>> > We can get a match for those locales in non-ISO format by enumerating
>> > available
On Mon, Apr 20, 2020 at 10:10 AM Amit Kapila
wrote:
> Yes, I am planning to look into it. Actually, I think the main thing
> here is to ensure that we don't break something which was working with
> _create_locale API.
I am trying to understand how lc_messages affect the error messages on
Window
On Mon, Apr 20, 2020 at 4:32 AM Michael Paquier wrote:
>
> On Sun, Apr 19, 2020 at 03:59:50PM -0300, Ranier Vilela wrote:
> > Em dom., 19 de abr. de 2020 às 12:34, Juan José Santamaría Flecha <
> > juanjo.santama...@gmail.com> escreveu:
> >> This line needs a break, other than that LGTM.
> >
> > S
On Sun, Apr 19, 2020 at 03:59:50PM -0300, Ranier Vilela wrote:
> Em dom., 19 de abr. de 2020 às 12:34, Juan José Santamaría Flecha <
> juanjo.santama...@gmail.com> escreveu:
>> This line needs a break, other than that LGTM.
>
> Sure. Attached new patch with this revision.
Amit, are you planning to
Em dom., 19 de abr. de 2020 às 12:34, Juan José Santamaría Flecha <
juanjo.santama...@gmail.com> escreveu:
>
> On Sun, Apr 19, 2020 at 1:58 PM Ranier Vilela wrote:
>
>> Em dom., 19 de abr. de 2020 às 07:16, Juan José Santamaría Flecha <
>> juanjo.santama...@gmail.com> escreveu:
>>
>>> On Sat, Apr
On Sun, Apr 19, 2020 at 1:58 PM Ranier Vilela wrote:
> Em dom., 19 de abr. de 2020 às 07:16, Juan José Santamaría Flecha <
> juanjo.santama...@gmail.com> escreveu:
>
>> On Sat, Apr 18, 2020 at 1:43 PM Ranier Vilela
>> wrote:
>>
>>> I have some observations about this patch, related to style, if
Em dom., 19 de abr. de 2020 às 07:16, Juan José Santamaría Flecha <
juanjo.santama...@gmail.com> escreveu:
>
> On Sat, Apr 18, 2020 at 6:07 AM Amit Kapila
> wrote:
>
>> On Sat, Apr 18, 2020 at 12:14 AM Juan José Santamaría Flecha
>> wrote:
>> >
>> > We can get a match for those locales in non-IS
On Sat, Apr 18, 2020 at 6:07 AM Amit Kapila wrote:
> On Sat, Apr 18, 2020 at 12:14 AM Juan José Santamaría Flecha
> wrote:
> >
> > We can get a match for those locales in non-ISO format by enumerating
> available locales with EnumSystemLocalesEx(), and trying to find a match.
>
> I have not revi
Em sex., 17 de abr. de 2020 às 15:44, Juan José Santamaría Flecha <
juanjo.santama...@gmail.com> escreveu:
>
> On Fri, Apr 17, 2020 at 10:33 AM Amit Kapila
> wrote:
>
>>
>> I see some differences in the output when _create_locale() is used vs.
>> when GetLocaleInfoEx() is used. Forex.
>>
>
> Tha
On Sat, Apr 18, 2020 at 12:14 AM Juan José Santamaría Flecha
wrote:
>
>
> We can get a match for those locales in non-ISO format by enumerating
> available locales with EnumSystemLocalesEx(), and trying to find a match.
>
> Please find a new patch for so.
>
I have not reviewed or tested the new
On Fri, Apr 17, 2020 at 10:33 AM Amit Kapila
wrote:
>
> I see some differences in the output when _create_locale() is used vs.
> when GetLocaleInfoEx() is used. Forex.
>
Thanks for the thorough review.
> The function IsoLocaleName() header comment says "Convert a Windows
> setlocale() argumen
On Wed, Apr 15, 2020 at 11:58 PM Juan José Santamaría Flecha
wrote:
>
> On Wed, Apr 15, 2020 at 4:46 PM Ranier Vilela wrote:
>>
>> Em qua., 15 de abr. de 2020 às 03:08, davinder singh
>> escreveu:
>>>
>>>
5. Why call _create_locale if _WIN32_WINNT >= 0x0600 is true and loct is
not us
Em qua., 15 de abr. de 2020 às 15:28, Juan José Santamaría Flecha <
juanjo.santama...@gmail.com> escreveu:
>
>
> On Wed, Apr 15, 2020 at 4:46 PM Ranier Vilela wrote:
>
>> Em qua., 15 de abr. de 2020 às 03:08, davinder singh <
>> davindersingh2...@gmail.com> escreveu:
>>
>>>
>>> 5. Why call _creat
On Wed, Apr 15, 2020 at 4:46 PM Ranier Vilela wrote:
> Em qua., 15 de abr. de 2020 às 03:08, davinder singh <
> davindersingh2...@gmail.com> escreveu:
>
>>
>> 5. Why call _create_locale if _WIN32_WINNT >= 0x0600 is true and loct is
>>> not used?
>>>
>> _create_locale can take bigger input than Ge
Em qua., 15 de abr. de 2020 às 03:08, davinder singh <
davindersingh2...@gmail.com> escreveu:
>
> Thanks for the review comments.
>
> On Tue, Apr 14, 2020 at 9:12 PM Ranier Vilela wrote:
>
>> >>I m still working on testing this patch. If anyone has Idea please
>> suggest.
>> I still see problems
Thanks for the review comments.
On Tue, Apr 14, 2020 at 9:12 PM Ranier Vilela wrote:
> >>I m still working on testing this patch. If anyone has Idea please
> suggest.
> I still see problems with this patch.
>
> 1. Variable loct have redundant initialization, it would be enough to
> declare so: _
On Fri, Apr 10, 2020 at 5:33 PM Amit Kapila wrote:
>
> It seems the right direction to use GetLocaleInfoEx as we have already
> used it to handle a similar problem (lc_codepage is missing in
> _locale_t in higher versions of MSVC (cf commit 0fb54de9aa)) in
> chklocale.c. However, I see that we ha
On Fri, Apr 10, 2020 at 2:25 PM Amit Kapila wrote:
>
> I see that the kind of check you are talking is recently added by
> commit 352f6f2d. I think it is better to be consistent in all places.
> Let's pick one and use that if possible.
Currently there are two constructs to test the same logic,
On Fri, Apr 10, 2020 at 5:35 PM Amit Kapila wrote:
>
> On Tue, Apr 7, 2020 at 8:30 PM Juan José Santamaría Flecha
> wrote:
> >
> > * I think you could save a couple of code lines, and make it clearer, by
> > merging both tests on _MSC_VER into a single #if... #else and leaving as
> > common c
On Tue, Apr 7, 2020 at 8:30 PM Juan José Santamaría Flecha
wrote:
>
> * I think you could save a couple of code lines, and make it clearer, by
> merging both tests on _MSC_VER into a single #if... #else and leaving as
> common code:
> + }
> + else
> + return NULL;
> +#endif /*_MSC_VER && _MSC_
On Mon, Apr 6, 2020 at 4:38 PM davinder singh
wrote:
>
> Hi All,
>
> I am working on “pg_locale compilation error with Visual Studio 2017”,
> Related threads[1],[2].
> We are getting compilation error in static char *IsoLocaleName(const char
> *winlocname) function in pg_locale.c file. This func
Em qui., 9 de abr. de 2020 às 09:14, Juan José Santamaría Flecha <
juanjo.santama...@gmail.com> escreveu:
>
> On Thu, Apr 9, 2020 at 1:56 PM Ranier Vilela wrote:
>
>> Attached, your patch with those considerations.
>>
> I see no attachment.
>
Sorry, my mystake.
regards,
Ranier Vilela
0001-PG-c
On Thu, Apr 9, 2020 at 1:56 PM Ranier Vilela wrote:
> Attached, your patch with those considerations.
>
I see no attachment.
Regards
>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
>> reappea
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
On Wed, Apr 8, 2020 at 9:03 AM davinder singh
wrote:
> On Tue, Apr 7, 2020 at 8:30 PM Juan José Santamaría Flecha <
> juanjo.santama...@gmail.com> wrote:
>
>>
>> * The logic on "defined(_MSC_VER) && (_MSC_VER >= 1900)" is defined as
>> "_WIN32_WINNT >= 0x0600" on other parts of the code. I would
On Tue, Apr 7, 2020 at 8:30 PM Juan José Santamaría Flecha <
juanjo.santama...@gmail.com> wrote:
>
> * The logic on "defined(_MSC_VER) && (_MSC_VER >= 1900)" is defined as
> "_WIN32_WINNT >= 0x0600" on other parts of the code. I would
> recommend using the later.
>
I think "_WIN32_WINNT >= 0x0600
On Tue, Apr 7, 2020 at 7:44 AM davinder singh
wrote:
>
> You need to enable NLS support in the config file. Let me know if that
> answers your question.
>
Yes, I can see where this is coming from now, thanks.
Currently, it is using _create_locale it behaves similarly to
> GetLocaleInfoEx i.e. i
On Mon, Apr 6, 2020 at 8:17 PM Juan José Santamaría Flecha <
juanjo.santama...@gmail.com> wrote:
>
> How do you reproduce this issue with Visual Studio? I see there is an
> ifdef directive above IsoLocaleName():
>
> #if defined(WIN32) && defined(LC_MESSAGES)
>
> I would expect defined(LC_MESSAGES
On Mon, Apr 6, 2020 at 1:08 PM davinder singh
wrote:
>
> I am working on “pg_locale compilation error with Visual Studio 2017”,
> Related threads[1],[2].
> We are getting compilation error in static char *IsoLocaleName(const char
> *winlocname) function in pg_locale.c file. This function is tryin
75 matches
Mail list logo
