On Sat, Apr 30, 2016 at 12:22 AM, Petr Jelinek wrote:
> After bit of fighting with the system the "caecilian" reported first
> successful build to the buildfarm.
Thanks! The fight was there as well.
--
Michael
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make chang
On 29/04/16 16:02, Michael Paquier wrote:
On Fri, Apr 29, 2016 at 9:13 PM, Andrew Dunstan wrote:
Yeah, I noticed the ugliness, should have fixed it. Applied your fix and
committed.
Thanks for the commit!
+1
After bit of fighting with the system the "caecilian" reported first
successful b
On Fri, Apr 29, 2016 at 9:13 PM, Andrew Dunstan wrote:
> Yeah, I noticed the ugliness, should have fixed it. Applied your fix and
> committed.
Thanks for the commit!
Nitpick comment:
+ * Also for VS2015, add a define that stops compiler complaints about
Two spaces instead of one between "Also"
On 04/29/2016 12:39 AM, Tom Lane wrote:
Andrew Dunstan writes:
latest patch attached. I have also cleaned up the docs some, and removed
references to the now redundant msysGit.
Please don't do stuff like this:
@@ -232,6 +265,10 @@ win32_langinfo(const char *ctype)
if (r != N
Andrew Dunstan writes:
> latest patch attached. I have also cleaned up the docs some, and removed
> references to the now redundant msysGit.
Please don't do stuff like this:
@@ -232,6 +265,10 @@ win32_langinfo(const char *ctype)
if (r != NULL)
sprintf(r,
On 04/25/2016 03:11 AM, Michael Paquier wrote:
On Mon, Apr 25, 2016 at 4:29 AM, Christian Ullrich wrote:
Andrew wrote:
OK, here's my final version of the patch, which I will apply in 24 hours
or so unless there is an objection.
Thanks Andrew for the updated patch!
This one doesn't matter
On Mon, Apr 25, 2016 at 4:29 AM, Christian Ullrich wrote:
> Andrew wrote:
>> OK, here's my final version of the patch, which I will apply in 24 hours
> or so unless there is an objection.
Thanks Andrew for the updated patch!
> This one doesn't matter, but just for perfection's sake:
>
> +#if (_M
* Andrew Dunstan wrote:
OK, here's my final version of the patch, which I will apply in 24 hours
or so unless there is an objection.
+ Visual Studio 2008 and above. Compilation
+ is supported down to Windows XP and
+ Windows Server 2003 when building with
+ Visual Studio 2005 to
+ Visual
* Andrew Dunstan wrote:
On 04/24/2016 03:16 PM, Christian Ullrich wrote:
* Andrew Dunstan wrote:
msvcr120.dll seems to be the highest numbered one on my system, and we
already cover that. If you like we can add to the comments in that file.
There won't be a higher one, with VS 2015, CRT
On 04/24/2016 03:16 PM, Christian Ullrich wrote:
* Andrew Dunstan wrote:
On 04/24/2016 12:14 PM, Tom Lane wrote:
Andrew Dunstan writes:
OK, here's my final version of the patch, which I will apply in 24
hours
or so unless there is an objection.
BTW, in view of 9f633b404, shouldn't th
* Andrew Dunstan wrote:
On 04/24/2016 12:14 PM, Tom Lane wrote:
Andrew Dunstan writes:
OK, here's my final version of the patch, which I will apply in 24 hours
or so unless there is an objection.
BTW, in view of 9f633b404, shouldn't there be a similar addition to
win32env.c in this patch
Andrew Dunstan writes:
> On 04/24/2016 12:14 PM, Tom Lane wrote:
>> BTW, in view of 9f633b404, shouldn't there be a similar addition to
>> win32env.c in this patch?
> msvcr120.dll seems to be the highest numbered one on my system, and we
> already cover that. If you like we can add to the commen
On 04/24/2016 12:14 PM, Tom Lane wrote:
Andrew Dunstan writes:
OK, here's my final version of the patch, which I will apply in 24 hours
or so unless there is an objection.
BTW, in view of 9f633b404, shouldn't there be a similar addition to
win32env.c in this patch?
Andrew Dunstan writes:
> On 04/24/2016 11:58 AM, Tom Lane wrote:
>> Hmm ... does this pragma work on *every* compiler we're going to use
>> on Windows?
> According to my research it works on all the MSVC versions we support. I
> didn't research the others (i.e. gcc), but we already use the pragm
On 04/24/2016 11:58 AM, Tom Lane wrote:
Andrew Dunstan writes:
OK, here's my final version of the patch, which I will apply in 24 hours
or so unless there is an objection.
+#pragma warning(push)
+#pragma warning(disable : 4091)
#include
+#pragma warning(pop)
Hmm ... does this pragma work
Andrew Dunstan writes:
> OK, here's my final version of the patch, which I will apply in 24 hours
> or so unless there is an objection.
BTW, in view of 9f633b404, shouldn't there be a similar addition to
win32env.c in this patch?
regards, tom lane
--
Sent via pgsql-ha
Andrew Dunstan writes:
> OK, here's my final version of the patch, which I will apply in 24 hours
> or so unless there is an objection.
> +#pragma warning(push)
> +#pragma warning(disable : 4091)
> #include
> +#pragma warning(pop)
Hmm ... does this pragma work on *every* compiler we're going
On 04/23/2016 11:25 PM, Andrew Dunstan wrote:
On 04/23/2016 06:33 PM, Tom Lane wrote:
I wrote:
Andrew Dunstan writes:
On 04/23/2016 05:30 PM, Christian Ullrich wrote:
In this case, I would prefer this:
#ifdef WIN32_ONLY_COMPILER
-typedef int pid_t;
+typedef intptr_t pid_t;
#endif
That'
On 23/04/16 08:08, Christian Ullrich wrote:
* Christian Ullrich wrote:
* Andrew Dunstan wrote:
On 04/22/2016 02:46 AM, Michael Paquier wrote:
Progress report:
1. My VS 2015 installations (I now have several) all generate
solution file
with:
Microsoft Visual Studio Solution File, Forma
On 04/23/2016 06:33 PM, Tom Lane wrote:
I wrote:
Andrew Dunstan writes:
On 04/23/2016 05:30 PM, Christian Ullrich wrote:
In this case, I would prefer this:
#ifdef WIN32_ONLY_COMPILER
-typedef int pid_t;
+typedef intptr_t pid_t;
#endif
That's a change that will have a pretty wide effect. E
I wrote:
> Andrew Dunstan writes:
>> On 04/23/2016 05:30 PM, Christian Ullrich wrote:
>>> In this case, I would prefer this:
>>>
>>> #ifdef WIN32_ONLY_COMPILER
>>> -typedef int pid_t;
>>> +typedef intptr_t pid_t;
>>> #endif
>> That's a change that will have a pretty wide effect. Everything up to
Andrew Dunstan writes:
> On 04/23/2016 05:30 PM, Christian Ullrich wrote:
>> In this case, I would prefer this:
>>
>> #ifdef WIN32_ONLY_COMPILER
>> -typedef int pid_t;
>> +typedef intptr_t pid_t;
>> #endif
> That's a change that will have a pretty wide effect. Everything up to
> now has been pre
On 04/23/2016 05:30 PM, Christian Ullrich wrote:
* Andrew Dunstan wrote:
On 04/22/2016 01:21 AM, Michael Paquier wrote:
5. It also complains about us casting a pid_t to a HANDLE in
pg_basebackup.c. Not sure what to do about that.
The thing that's being cast is not a PID, but a HANDLE to a
* Andrew Dunstan wrote:
On 04/22/2016 01:21 AM, Michael Paquier wrote:
5. It also complains about us casting a pid_t to a HANDLE in
pg_basebackup.c. Not sure what to do about that.
The thing that's being cast is not a PID, but a HANDLE to a process.
pid_t is a typedef for int (in port/win32.
On 04/22/2016 01:21 AM, Michael Paquier wrote:
5. It also complains about us casting a pid_t to a HANDLE in
pg_basebackup.c. Not sure what to do about that.
The thing that's being cast is not a PID, but a HANDLE to a process. pid_t is a
typedef for int (in port/win32.h), therefore is always 3
* Christian Ullrich wrote:
* Andrew Dunstan wrote:
On 04/22/2016 02:46 AM, Michael Paquier wrote:
Progress report:
1. My VS 2015 installations (I now have several) all generate
solution file
with:
Microsoft Visual Studio Solution File, Format Version 12.00
so I propose to set that as t
* Andrew Dunstan wrote:
On 04/22/2016 02:46 AM, Michael Paquier wrote:
Progress report:
1. My VS 2015 installations (I now have several) all generate
solution file
with:
Microsoft Visual Studio Solution File, Format Version 12.00
so I propose to set that as the solution file version.
>>
Michael Paquier writes:
> On Fri, Apr 22, 2016 at 10:49 PM, Tom Lane wrote:
>> How far back are we thinking of supporting VS2015, anyway? I can check
>> and push this as a separate patch.
> My guess is 9.5: HEAD + last stable branch. That's what has been done
> when support for VS2012 or VS2013
On 04/22/2016 02:46 AM, Michael Paquier wrote:
Progress report:
1. My VS 2015 installations (I now have several) all generate solution file
with:
Microsoft Visual Studio Solution File, Format Version 12.00
so I propose to set that as the solution file version.
I am wondering why it happ
On Fri, Apr 22, 2016 at 10:49 PM, Tom Lane wrote:
> How far back are we thinking of supporting VS2015, anyway? I can check
> and push this as a separate patch.
My guess is 9.5: HEAD + last stable branch. That's what has been done
when support for VS2012 or VS2013 has been added.
--
Michael
--
Michael Paquier writes:
> On Fri, Apr 22, 2016 at 1:30 PM, Tom Lane wrote:
>> If we assume that oldstyle functions returning integer are still okay,
>> which the success of the regression test case involving oldstyle_length()
>> seems to prove, then indeed seg's bool-returning functions are the o
On Fri, Apr 22, 2016 at 1:30 PM, Tom Lane wrote:
> Andrew Dunstan writes:
>> On 04/21/2016 05:15 PM, Tom Lane wrote:
>>> Do the other contrib modules all pass? I can't recall if seg was the
>>> only one we'd left like this.
>
>> Only seg fails.
>
> As a crosscheck, I put some code into fmgr_c_va
On Fri, Apr 22, 2016 at 4:39 AM, Andrew Dunstan wrote:
> On 04/11/2016 03:47 AM, Michael Paquier wrote:
>> On Mon, Apr 11, 2016 at 3:25 PM, Michael Paquier
>> wrote:
>>>
>>> Now, I have produced two patches:
>>> - 0001-Support-for-VS-2015-locale-hack.patch, which makes use of
>>> __crt_locale_dat
On Fri, Apr 22, 2016 at 4:56 AM, Christian Ullrich wrote:
> * From: Andrew Dunstan [mailto:and...@dunslane.net]
>
>> 4. The compiler complains about one of Microsoft's own header files -
>> essentially it dislikes the=is construct:
>>
>> typedef enum { ... };
>>
>> It would be nice to make it
Andrew Dunstan writes:
> On 04/21/2016 05:15 PM, Tom Lane wrote:
>> Do the other contrib modules all pass? I can't recall if seg was the
>> only one we'd left like this.
> Only seg fails.
As a crosscheck, I put some code into fmgr_c_validator() to log a message
when creating a V0 function with
On 04/21/2016 05:15 PM, Tom Lane wrote:
IIRC, we had intentionally left contrib/seg using mostly V0 calling
convention as a canary to let us know when that broke. It's a bit
astonishing that it lasted this long, maybe. But it looks like we're
going to have to convert at least the bool-return
Andrew Dunstan writes:
> 5. most importantly, on my Release/X64 build, I am getting a regression
> failure on contrib/seg. regression diffs attached. Until that's fixed
> this isn't going anywhere.
I'll bet a nickel that this means MSVC has broken the ABI rules that
allowed old-style (version 0
* From: Andrew Dunstan [mailto:and...@dunslane.net]
> 4. The compiler complains about one of Microsoft's own header files -
> essentially it dislikes the=is construct:
>
> typedef enum { ... };
>
> It would be nice to make it shut up about it.
I doubt that's possible; the declaration *is* w
On 04/11/2016 03:47 AM, Michael Paquier wrote:
On Mon, Apr 11, 2016 at 3:25 PM, Michael Paquier
wrote:
Now, I have produced two patches:
- 0001-Support-for-VS-2015-locale-hack.patch, which makes use of
__crt_locale_data_public in ucrt/corecrt.h. This is definitely an ugly
hack, though I am co
On Wed, Apr 20, 2016 at 02:03:16PM +0900, Michael Paquier wrote:
> On Wed, Apr 20, 2016 at 1:39 PM, Noah Misch wrote:
> > On Tue, Apr 19, 2016 at 02:42:24AM -0300, Alvaro Herrera wrote:
> >> This thread seems to have stalled. I thought we were going to consider
> >> these patches for 9.6.
> >
> >
On Wed, Apr 20, 2016 at 1:39 PM, Noah Misch wrote:
> On Tue, Apr 19, 2016 at 02:42:24AM -0300, Alvaro Herrera wrote:
>> Michael Paquier wrote:
>> > On Mon, Apr 11, 2016 at 3:25 PM, Michael Paquier
>> > wrote:
>> > > Now, I have produced two patches:
>> > > - 0001-Support-for-VS-2015-locale-hack.p
* Michael Paquier wrote:
On Wed, Apr 20, 2016 at 1:48 AM, Christian Ullrich wrote:
Both patches behave exactly the same in this test. Of the 102 remaining
locales, I get an unexpected codepage for just four:
- kk: Expected 1251, used 1252
- kk-KZ: Expected 1251, used 1252
- sr: Expected 1251,
On Tue, Apr 19, 2016 at 02:42:24AM -0300, Alvaro Herrera wrote:
> Michael Paquier wrote:
> > On Mon, Apr 11, 2016 at 3:25 PM, Michael Paquier
> > wrote:
> > > Now, I have produced two patches:
> > > - 0001-Support-for-VS-2015-locale-hack.patch, which makes use of
> > > __crt_locale_data_public in
On Wed, Apr 20, 2016 at 1:48 AM, Christian Ullrich wrote:
> Both patches behave exactly the same in this test. Of the 102 remaining
> locales, I get an unexpected codepage for just four:
>
> - kk: Expected 1251, used 1252
> - kk-KZ: Expected 1251, used 1252
> - sr: Expected 1251, used 1250
> - uk:
* Alvaro Herrera wrote:
Michael Paquier wrote:
On Mon, Apr 11, 2016 at 3:25 PM, Michael Paquier
wrote:
Now, I have produced two patches:
- 0001-Support-for-VS-2015-locale-hack.patch, which makes use of
__crt_locale_data_public in ucrt/corecrt.h. This is definitely an ugly
hack, though I am co
On 04/19/2016 01:47 AM, Michael Paquier wrote:
On Tue, Apr 19, 2016 at 2:42 PM, Alvaro Herrera
wrote:
Michael Paquier wrote:
On Mon, Apr 11, 2016 at 3:25 PM, Michael Paquier
wrote:
Now, I have produced two patches:
- 0001-Support-for-VS-2015-locale-hack.patch, which makes use of
__crt_loca
On Tue, Apr 19, 2016 at 2:42 PM, Alvaro Herrera
wrote:
> Michael Paquier wrote:
>> On Mon, Apr 11, 2016 at 3:25 PM, Michael Paquier
>> wrote:
>> > Now, I have produced two patches:
>> > - 0001-Support-for-VS-2015-locale-hack.patch, which makes use of
>> > __crt_locale_data_public in ucrt/corecrt.
Michael Paquier wrote:
> On Mon, Apr 11, 2016 at 3:25 PM, Michael Paquier
> wrote:
> > Now, I have produced two patches:
> > - 0001-Support-for-VS-2015-locale-hack.patch, which makes use of
> > __crt_locale_data_public in ucrt/corecrt.h. This is definitely an ugly
> > hack, though I am coming to t
On Mon, Apr 11, 2016 at 3:25 PM, Michael Paquier
wrote:
> Now, I have produced two patches:
> - 0001-Support-for-VS-2015-locale-hack.patch, which makes use of
> __crt_locale_data_public in ucrt/corecrt.h. This is definitely an ugly
> hack, though I am coming to think that this may be the approach
On Mon, Apr 11, 2016 at 6:03 AM, Petr Jelinek wrote:
> On 10/04/16 20:47, Christian Ullrich wrote:
>>> don't think we need to be too precious about saving a byte or two
>>> here. Can one or other of you please prepare a replacement patch based
>>> in this discussion?
So, I am finally back on the
On 10/04/16 20:47, Christian Ullrich wrote:
* Andrew Dunstan:
On 04/09/2016 08:43 AM, Christian Ullrich wrote:
Michael Paquier wrote:
I don't think that's good to use malloc in those code paths, and I
Oh?
+#if (_MSC_VER >= 1900)
+uint32cp;
+
+if (GetLocaleInfoEx(ctype,
+
* Andrew Dunstan:
On 04/09/2016 08:43 AM, Christian Ullrich wrote:
Michael Paquier wrote:
I don't think that's good to use malloc in those code paths, and I
Oh?
+#if (_MSC_VER >= 1900)
+ uint32 cp;
+
+ if (GetLocaleInfoEx(ctype,
+ LOCALE_IDEFAULTANSICO
On 04/09/2016 08:43 AM, Christian Ullrich wrote:
Michael Paquier wrote:
On Sat, Apr 9, 2016 at 7:41 AM, Michael Paquier
wrote:
On Sat, Apr 9, 2016 at 1:46 AM, Christian Ullrich wrote:
* Andrew Dunstan wrote:
On 04/08/2016 11:02 AM, Christian Ullrich wrote:
src/port/chklocale.c(233): war
> Michael Paquier wrote:
>
> On Sat, Apr 9, 2016 at 7:41 AM, Michael Paquier
> wrote:
>> On Sat, Apr 9, 2016 at 1:46 AM, Christian Ullrich
>> wrote:
>>> * Andrew Dunstan wrote:
> On 04/08/2016 11:02 AM, Christian Ullrich wrote:
> src/port/chklocale.c(233): warning C4133: 'function': i
On Sat, Apr 9, 2016 at 7:41 AM, Michael Paquier
wrote:
> On Sat, Apr 9, 2016 at 1:46 AM, Christian Ullrich
> wrote:
>> * Andrew Dunstan wrote:
>>> On 04/08/2016 11:02 AM, Christian Ullrich wrote:
src/port/chklocale.c(233): warning C4133: 'function': incompatible
types - from 'const
On 09/04/16 00:41, Michael Paquier wrote:
On Sat, Apr 9, 2016 at 1:46 AM, Christian Ullrich wrote:
* Andrew Dunstan wrote:
On 04/08/2016 11:02 AM, Christian Ullrich wrote:
src/port/chklocale.c(233): warning C4133: 'function': incompatible
types - from 'const char *' to 'LPCWSTR' [..
On Sat, Apr 9, 2016 at 1:46 AM, Christian Ullrich wrote:
> * Andrew Dunstan wrote:
>
>> On 04/08/2016 11:02 AM, Christian Ullrich wrote:
>
>
>>> src/port/chklocale.c(233): warning C4133: 'function': incompatible
>>> types - from 'const char *' to 'LPCWSTR' [...\postgres.vcxproj]
>
>
>> Do you
* Andrew Dunstan wrote:
On 04/08/2016 11:02 AM, Christian Ullrich wrote:
src/port/chklocale.c(233): warning C4133: 'function': incompatible
types - from 'const char *' to 'LPCWSTR' [...\postgres.vcxproj]
Do you have a fix for the LPCWSTR parameter issue?
As long as the locale short n
On 04/08/2016 11:02 AM, Christian Ullrich wrote:
* Michael Paquier wrote:
On Fri, Apr 8, 2016 at 10:05 PM, Andrew Dunstan
wrote:
¥> On 04/08/2016 07:15 AM, Christian Ullrich wrote:
Michael, none of your patches change this, so how does it ever
build on
your system?
Luck. I am getting
* Michael Paquier wrote:
On Fri, Apr 8, 2016 at 10:05 PM, Andrew Dunstan wrote:
¥> On 04/08/2016 07:15 AM, Christian Ullrich wrote:
Michael, none of your patches change this, so how does it ever build on
your system?
Luck. I am getting a warning but the code is able to somewhat compile:
On Fri, Apr 8, 2016 at 4:12 PM, Michael Paquier
wrote:
> On Fri, Apr 8, 2016 at 10:05 PM, Andrew Dunstan
> wrote:
> ¥> On 04/08/2016 07:15 AM, Christian Ullrich wrote:
> >> GetLocaleInfoEx() is covered by #if (WINVER >= 0x0600), we define
> >> _WIN32_WINNT as 0x0501 (src/include/port/win32.h) an
On Fri, Apr 8, 2016 at 10:05 PM, Andrew Dunstan wrote:
¥> On 04/08/2016 07:15 AM, Christian Ullrich wrote:
>> GetLocaleInfoEx() is covered by #if (WINVER >= 0x0600), we define
>> _WIN32_WINNT as 0x0501 (src/include/port/win32.h) and WINVER inherits that
>> value.
Yes, I had a look at winnls.h and
On 04/08/2016 09:52 AM, Tom Lane wrote:
Andrew Dunstan writes:
OK, at this stage it appears to me that if today is the deadline for
getting this in for 9.6 then it's going to be missed.
It would be unfortunate to go another year without support for that
toolchain. My suggestion is that you
Andrew Dunstan writes:
> OK, at this stage it appears to me that if today is the deadline for
> getting this in for 9.6 then it's going to be missed.
It would be unfortunate to go another year without support for that
toolchain. My suggestion is that you continue to work away on the
problem, an
On 04/08/2016 07:15 AM, Christian Ullrich wrote:
* Michael Paquier wrote:
> On Fri, Apr 8, 2016 at 9:29 AM, Andrew Dunstan
> wrote:
Not out of the woods yet. Attached is what I got from VS2015 on a
fresh W10
VM, with Michael's patch 0002 and 0004 applied.
Interesting, I have no idea wh
* Michael Paquier wrote:
> On Fri, Apr 8, 2016 at 9:29 AM, Andrew Dunstan
> wrote:
Not out of the woods yet. Attached is what I got from VS2015 on a fresh W10
VM, with Michael's patch 0002 and 0004 applied.
Interesting, I have no idea what we are doing differently, and seeing
those errors
On Fri, Apr 8, 2016 at 9:29 AM, Andrew Dunstan wrote:
> Not out of the woods yet. Attached is what I got from VS2015 on a fresh W10
> VM, with Michael's patch 0002 and 0004 applied.
Interesting, I have no idea what we are doing differently, and seeing
those errors it seems to me that Petr and I a
On 04/06/2016 04:50 PM, Andrew Dunstan wrote:
On 03/29/2016 09:38 PM, Robert Haas wrote:
On Tue, Mar 29, 2016 at 9:29 PM, Andrew Dunstan
wrote:
I am currently travelling, but my intention is to deal with the
remaining
patches when I'm back home this weekend, unless someone beats me to it.
* Petr Jelinek wrote:
On 07/04/16 00:50, Michael Paquier wrote:
On Thu, Apr 7, 2016 at 7:44 AM, Michael Paquier
wrote:
On Thu, Apr 7, 2016 at 6:11 AM, Petr Jelinek
wrote:
On 06/04/16 22:50, Andrew Dunstan wrote:
* VS2015 appears to create version 12 solution files, not
version 14
On Thu, Apr 7, 2016 at 7:44 AM, Michael Paquier
wrote:
> On Thu, Apr 7, 2016 at 6:11 AM, Petr Jelinek wrote:
>> On 06/04/16 22:50, Andrew Dunstan wrote:
>>> I have spent way too much time on this and don't have it working yet.
>>> I'm setting up a sacrificial VM from scratch in a last ditch attem
On 07/04/16 00:50, Michael Paquier wrote:
On Thu, Apr 7, 2016 at 7:44 AM, Michael Paquier
wrote:
On Thu, Apr 7, 2016 at 6:11 AM, Petr Jelinek wrote:
On 06/04/16 22:50, Andrew Dunstan wrote:
I have spent way too much time on this and don't have it working yet.
I'm setting up a sacrificial VM
On Thu, Apr 7, 2016 at 6:11 AM, Petr Jelinek wrote:
> On 06/04/16 22:50, Andrew Dunstan wrote:
>> I have spent way too much time on this and don't have it working yet.
>> I'm setting up a sacrificial VM from scratch in a last ditch attempt to
>> get it working.
>>
>> Things to note so far:
>>
>>
Petr Jelinek wrote:
> It's fun to set it up yes. I do have the machine with buildfarm client ready
> still (although now also traveling so slightly complicated to get to it) but
> I didn't activate it yet as I don't want it to just report failures forever.
Maybe you should just activate it regard
On 06/04/16 22:50, Andrew Dunstan wrote:
On 03/29/2016 09:38 PM, Robert Haas wrote:
On Tue, Mar 29, 2016 at 9:29 PM, Andrew Dunstan
wrote:
I am currently travelling, but my intention is to deal with the
remaining
patches when I'm back home this weekend, unless someone beats me to it.
Cool.
On 03/29/2016 09:38 PM, Robert Haas wrote:
On Tue, Mar 29, 2016 at 9:29 PM, Andrew Dunstan wrote:
I am currently travelling, but my intention is to deal with the remaining
patches when I'm back home this weekend, unless someone beats me to it.
Cool.
Progress report:
I have spent way too
On Tue, Mar 29, 2016 at 9:29 PM, Andrew Dunstan wrote:
> I am currently travelling, but my intention is to deal with the remaining
> patches when I'm back home this weekend, unless someone beats me to it.
Cool.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL C
On 03/29/2016 08:48 PM, Michael Paquier wrote:
On Wed, Mar 30, 2016 at 12:45 AM, Robert Haas wrote:
On Tue, Mar 29, 2016 at 11:31 AM, Petr Jelinek wrote:
I have machine ready, waiting for animal name and secret.
Great!
Nice. Thanks.
It will obviously
fail until we push the 0002 and 0004
On Wed, Mar 30, 2016 at 12:45 AM, Robert Haas wrote:
> On Tue, Mar 29, 2016 at 11:31 AM, Petr Jelinek wrote:
>> I have machine ready, waiting for animal name and secret.
>
> Great!
Nice. Thanks.
>> It will obviously
>> fail until we push the 0002 and 0004 though.
>
> I think it would be a shame
On Tue, Mar 29, 2016 at 11:31 AM, Petr Jelinek wrote:
> I have machine ready, waiting for animal name and secret.
Great!
> It will obviously
> fail until we push the 0002 and 0004 though.
I think it would be a shame if we shipped 9.6 without MSVC 2015
support, but it'd be nice if Andrew or Magn
On 29/03/16 03:06, Robert Haas wrote:
On Sun, Mar 27, 2016 at 10:35 PM, Michael Paquier
wrote:
On Fri, Mar 25, 2016 at 9:48 PM, Andrew Dunstan wrote:
OK, sounds good.
Just a side-note. Andres has pushed the fix for the GinIs* macros as
af4472bc, making patch 0003 from the last series useles
On Tue, Mar 29, 2016 at 10:06 AM, Robert Haas wrote:
> On Sun, Mar 27, 2016 at 10:35 PM, Michael Paquier
> wrote:
>> On Fri, Mar 25, 2016 at 9:48 PM, Andrew Dunstan wrote:
>>> OK, sounds good.
>>
>> Just a side-note. Andres has pushed the fix for the GinIs* macros as
>> af4472bc, making patch 00
On Sun, Mar 27, 2016 at 10:35 PM, Michael Paquier
wrote:
> On Fri, Mar 25, 2016 at 9:48 PM, Andrew Dunstan wrote:
>> OK, sounds good.
>
> Just a side-note. Andres has pushed the fix for the GinIs* macros as
> af4472bc, making patch 0003 from the last series useless now.
I'm not prepared to get v
On Fri, Mar 25, 2016 at 9:48 PM, Andrew Dunstan wrote:
> OK, sounds good.
Just a side-note. Andres has pushed the fix for the GinIs* macros as
af4472bc, making patch 0003 from the last series useless now.
--
Michael
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make
On Fri, Mar 25, 2016 at 9:48 PM, Andrew Dunstan wrote:
> OK, sounds good. I don't have a spare machine on which to install VS2015,
> nor time to set one up, so I'm going to have to trust the two of you
> (Michael and Petr) that this works.
With Virtual Box, you could set up an environment for dev
On Fri, Mar 25, 2016 at 9:55 PM, Robert Haas wrote:
> On Fri, Mar 25, 2016 at 8:31 AM, Michael Paquier
> wrote:
> The relationship between doc/src/sgml/install-windows.sgml, the
> section of doc/src/sgml/installation.sgml entitled "MinGW/Native
> Windows", and src/tools/msvc/README is not altoget
On Fri, Mar 25, 2016 at 8:31 AM, Michael Paquier
wrote:
> On Fri, Mar 25, 2016 at 9:09 PM, Robert Haas wrote:
>> On Thu, Mar 24, 2016 at 1:07 PM, Petr Jelinek wrote:
>>> On 24/03/16 17:28, Robert Haas wrote:
On Wed, Mar 23, 2016 at 3:17 AM, Michael Paquier
wrote:
>
> - 0001 fi
On 03/25/2016 08:31 AM, Michael Paquier wrote:
On Fri, Mar 25, 2016 at 9:09 PM, Robert Haas wrote:
On Thu, Mar 24, 2016 at 1:07 PM, Petr Jelinek wrote:
On 24/03/16 17:28, Robert Haas wrote:
On Wed, Mar 23, 2016 at 3:17 AM, Michael Paquier
wrote:
- 0001 fixes the global declarations of TI
On Fri, Mar 25, 2016 at 9:09 PM, Robert Haas wrote:
> On Thu, Mar 24, 2016 at 1:07 PM, Petr Jelinek wrote:
>> On 24/03/16 17:28, Robert Haas wrote:
>>> On Wed, Mar 23, 2016 at 3:17 AM, Michael Paquier
>>> wrote:
- 0001 fixes the global declarations of TIMEZONE_GLOBAL and
TZNAME_GL
On Thu, Mar 24, 2016 at 1:07 PM, Petr Jelinek wrote:
> On 24/03/16 17:28, Robert Haas wrote:
>> On Wed, Mar 23, 2016 at 3:17 AM, Michael Paquier
>> wrote:
>>>
>>> - 0001 fixes the global declarations of TIMEZONE_GLOBAL and
>>> TZNAME_GLOBAL to be WIN32-compliant. I got bitten by that in the ECPG
On 24/03/16 17:28, Robert Haas wrote:
On Wed, Mar 23, 2016 at 3:17 AM, Michael Paquier
wrote:
- 0001 fixes the global declarations of TIMEZONE_GLOBAL and
TZNAME_GLOBAL to be WIN32-compliant. I got bitten by that in the ECPG
compilation.
So this isn't going to break other Windows builds? I me
On Wed, Mar 23, 2016 at 3:17 AM, Michael Paquier
wrote:
> - 0001 fixes the global declarations of TIMEZONE_GLOBAL and
> TZNAME_GLOBAL to be WIN32-compliant. I got bitten by that in the ECPG
> compilation.
So this isn't going to break other Windows builds? I mean, if we've
got the names for those
On Thu, Mar 24, 2016 at 5:18 AM, Petr Jelinek wrote:
> Hmm I see you are right, I missed the last couple emails. Ok I'll mark it
> ready for committer - it does work fine on my vs2015 machine and I am happy
> with the code too.
Thanks, let's see what others have to say.
> Well, as happy as I can
On 23/03/16 13:05, Michael Paquier wrote:
OK, the please send an updated set of patches for what remains.
Here you go:
- 0001 fixes the global declarations of TIMEZONE_GLOBAL and
TZNAME_GLOBAL to be WIN32-compliant. I got bitten by that in the ECPG
compilation.
- 0002, support of VS2015 in th
On Wed, Mar 23, 2016 at 8:45 PM, Petr Jelinek wrote:
> On 23/03/16 08:17, Michael Paquier wrote:
>>
>> On Mon, Mar 21, 2016 at 3:43 AM, Andrew Dunstan
>> wrote:
>>>
>>>
>>>
>>> On 03/20/2016 12:02 AM, Michael Paquier wrote:
On Sun, Mar 20, 2016 at 8:06 AM, Andrew Dunstan
wrot
On 23/03/16 08:17, Michael Paquier wrote:
On Mon, Mar 21, 2016 at 3:43 AM, Andrew Dunstan wrote:
On 03/20/2016 12:02 AM, Michael Paquier wrote:
On Sun, Mar 20, 2016 at 8:06 AM, Andrew Dunstan
wrote:
Still to do: the non-perl pieces.
The patch to address locales is the sensitive part.
On Mon, Mar 21, 2016 at 3:43 AM, Andrew Dunstan wrote:
>
>
> On 03/20/2016 12:02 AM, Michael Paquier wrote:
>>
>> On Sun, Mar 20, 2016 at 8:06 AM, Andrew Dunstan
>> wrote:
>>>
>>>
>>> Still to do: the non-perl pieces.
>>
>> The patch to address locales is the sensitive part. The patch from
>> Pet
On 22/03/16 14:40, Michael Paquier wrote:
On Wed, Mar 9, 2016 at 11:10 PM, Petr Jelinek wrote:
Something like attached is simplest way this would work correctly (note that
I didn't really test it and it's missing comments). Note that we are falling
back to the old parsing in case the GetLocaleI
On Wed, Mar 9, 2016 at 11:10 PM, Petr Jelinek wrote:
> Something like attached is simplest way this would work correctly (note that
> I didn't really test it and it's missing comments). Note that we are falling
> back to the old parsing in case the GetLocaleInfoEx didn't work, that's
> important b
On 20/03/16 05:02, Michael Paquier wrote:
On Sun, Mar 20, 2016 at 8:06 AM, Andrew Dunstan wrote:
Still to do: the non-perl pieces.
The patch to address locales is the sensitive part. The patch from
Petr is taking the correct approach though I think that we had better
simplify it a bit and if
On 03/20/2016 12:02 AM, Michael Paquier wrote:
On Sun, Mar 20, 2016 at 8:06 AM, Andrew Dunstan wrote:
Still to do: the non-perl pieces.
The patch to address locales is the sensitive part. The patch from
Petr is taking the correct approach though I think that we had better
simplify it a bit
1 - 100 of 134 matches
Mail list logo
