Hi,
On 2018-08-25 13:08:18 -0400, Tom Lane wrote:
> Andres Freund writes:
> > On 2018-08-16 11:41:30 -0400, Tom Lane wrote:
> >> Andres Freund writes:
> >>> While I'd personally have no problem kicking gcc 3.4 to the curb, I'm
> >>> still confused what causes this error mode. Kinda looks like
>
Hi,
On 2018-09-11 16:13:15 -0400, Andrew Dunstan wrote:
> I've pushed support for the latest MSVC compilers back to all live branches.
Thanks!
Greetings,
Andres Freund
On 08/24/2018 03:42 PM, Andrew Dunstan wrote:
On 08/24/2018 02:38 PM, Tom Lane wrote:
Andres Freund writes:
On 2018-08-24 14:09:09 -0400, Andrew Dunstan wrote:
However, we only support VS2017 down to 9.6 and Vs2015 down to 9.5.
Perhaps
we should consider backpatching support for those d
Andres Freund writes:
> On 2018-08-16 11:41:30 -0400, Tom Lane wrote:
>> Andres Freund writes:
>>> While I'd personally have no problem kicking gcc 3.4 to the curb, I'm
>>> still confused what causes this error mode. Kinda looks like
>>> out-of-sync headers with gcc or something.
>> Yeah, this
On 08/24/2018 02:38 PM, Tom Lane wrote:
Andres Freund writes:
On 2018-08-24 14:09:09 -0400, Andrew Dunstan wrote:
However, we only support VS2017 down to 9.6 and Vs2015 down to 9.5. Perhaps
we should consider backpatching support for those down to 9.3.
Hm, I have no strong objections to th
On 08/24/2018 02:36 PM, Tom Lane wrote:
Andrew Dunstan writes:
I saw Tom's answer, and it will work as far as it goes. But maybe we
should look at doing that in configure instead of putting the onus on
all buildfarm owners? It already knows if it's using a GNU compiler, not
sure how ubiquito
Andres Freund writes:
> On 2018-08-24 14:09:09 -0400, Andrew Dunstan wrote:
>> However, we only support VS2017 down to 9.6 and Vs2015 down to 9.5. Perhaps
>> we should consider backpatching support for those down to 9.3.
> Hm, I have no strong objections to that. I don't think it's strictly
> n
Andrew Dunstan writes:
> I saw Tom's answer, and it will work as far as it goes. But maybe we
> should look at doing that in configure instead of putting the onus on
> all buildfarm owners? It already knows if it's using a GNU compiler, not
> sure how ubiquitous the -ansi and -std=c99 flags are
Hi,
On 2018-08-24 14:09:09 -0400, Andrew Dunstan wrote:
> I have installed VS2017 on bowerbird and a test is currently running. It's
> got past the make phase so I assume everything is kosher.
Cool, thanks.
> However, we only support VS2017 down to 9.6 and Vs2015 down to 9.5. Perhaps
> we should
On 08/24/2018 11:46 AM, Andres Freund wrote:
Hi,
On 2018-08-23 18:44:34 -0700, Andres Freund wrote:
Pushed the first two.
Seems to have worked like expected.
I'll send the presumably affected buildfarm owners an email, asking
them whether they want to update.
Did that.
I have install
On 2018-08-24 12:10:34 -0400, Tom Lane wrote:
> Andres Freund writes:
> > I'd like to change it so it doesn't enforce C89 compliance across the
> > board, but instead enforces the relevant standard. For that I'd need to
> > change CFLAGS per-branch in the buildfarm. Is that possible already? Do
>
Andres Freund writes:
> I'd like to change it so it doesn't enforce C89 compliance across the
> board, but instead enforces the relevant standard. For that I'd need to
> change CFLAGS per-branch in the buildfarm. Is that possible already? Do
> I need two different config files?
I just did that on
Hi,
On 2018-08-23 18:44:34 -0700, Andres Freund wrote:
> Pushed the first two.
Seems to have worked like expected.
> I'll send the presumably affected buildfarm owners an email, asking
> them whether they want to update.
Did that.
Andrew, as expected my buildfarm animal mylodon, which uses co
On Thu, Aug 16, 2018 at 12:24 PM, Thomas Munro
wrote:
> FWIW cfbot is using Visual Studio 2010 right now. Appveyor provides
> 2008, 2010, 2012, 2013 (AKA 12.0), 2015, 2017, and to test with a
> different toolchain you can take the example patch from
> https://wiki.postgresql.org/wiki/Continuous_I
On Fri, Aug 24, 2018 at 1:44 PM, Andres Freund wrote:
> On 2018-08-23 22:02:26 +0200, Peter Eisentraut wrote:
>> On 23/08/2018 03:31, Andres Freund wrote:
>> > On 2018-08-22 17:09:05 -0700, Andres Freund wrote:
>> >> Attached is a version doing so.
>> >
>> > Mildly updated version attached. This a
On 2018-08-23 22:02:26 +0200, Peter Eisentraut wrote:
> On 23/08/2018 03:31, Andres Freund wrote:
> > On 2018-08-22 17:09:05 -0700, Andres Freund wrote:
> >> Attached is a version doing so.
> >
> > Mildly updated version attached. This adds an explanatory commit
> > message, removes one stray docs
On 23/08/2018 03:31, Andres Freund wrote:
> On 2018-08-22 17:09:05 -0700, Andres Freund wrote:
>> Attached is a version doing so.
>
> Mildly updated version attached. This adds an explanatory commit
> message, removes one stray docs C89 reference, and fixes a mis-squashing
> of a patch.
Let's do
On 2018-08-22 17:09:05 -0700, Andres Freund wrote:
> Attached is a version doing so.
Mildly updated version attached. This adds an explanatory commit
message, removes one stray docs C89 reference, and fixes a mis-squashing
of a patch.
Greetings,
Andres Freund
>From 4b63f3307180a778018439ad3dee9a
Hi,
On 2018-08-22 20:16:24 -0400, Tom Lane wrote:
> Andres Freund writes:
> > There's a few further potential cleanups due to relying on c99:
> > - Use __func__ unconditionally, rather than having configure test for it
> > - Use inline unconditionally, rather than having configure test for it
> >
Andres Freund writes:
> There's a few further potential cleanups due to relying on c99:
> - Use __func__ unconditionally, rather than having configure test for it
> - Use inline unconditionally, rather than having configure test for it
> - Remove tests for AC_TYPE_INTPTR_T, AC_TYPE_UINTPTR_T,
>
Hi,
On 2018-08-22 05:02:11 -0700, Andres Freund wrote:
> If we agree on that, I'm going to propose a patch that includes:
> - relevant cleanups to configure
> - adapts sources.sgml to refer to C99 instead of C89
> - add some trivial conversions to for(int i;;) and struct initializers,
> so the r
On 8/22/18 10:56 AM, Peter Eisentraut wrote:
> On 22/08/2018 14:02, Andres Freund wrote:
>> If we agree on that, I'm going to propose a patch that includes:
>> - relevant cleanups to configure
>> - adapts sources.sgml to refer to C99 instead of C89
>> - add some trivial conversions to for(int i;;)
Hi,
On 2018-08-22 16:56:15 +0200, Peter Eisentraut wrote:
> On 22/08/2018 14:02, Andres Freund wrote:
> > - do we want to make declarations at arbitrary points errors? It's
> > already a warning currently.
>
> While there are legitimate criticisms, it's a standard feature in C,
> C++, and many
On 22/08/2018 14:02, Andres Freund wrote:
> If we agree on that, I'm going to propose a patch that includes:
> - relevant cleanups to configure
> - adapts sources.sgml to refer to C99 instead of C89
> - add some trivial conversions to for(int i;;) and struct initializers,
> so the relevant old an
On Wed, Aug 22, 2018 at 5:32 PM, Andres Freund wrote:
> Hi,
>
> On 2018-08-22 17:17:27 +0530, Sandeep Thakkar wrote:
> > > We build windows binaries (>=9.3) on Windows 7 and Windows Server 2012
> R2.
> > For 9.3, the Visual Studio version is 2010 and for 9.4 and v10, we use
> > 2013. For v11, we
Hi,
On 2018-08-22 17:17:27 +0530, Sandeep Thakkar wrote:
> > We build windows binaries (>=9.3) on Windows 7 and Windows Server 2012 R2.
> For 9.3, the Visual Studio version is 2010 and for 9.4 and v10, we use
> 2013. For v11, we use 2017.
Sndeep: Thanks for the information. Did you ever encounte
On Wed, Aug 22, 2018 at 4:59 AM, Andres Freund wrote:
> On 2018-08-21 17:58:00 -0400, Andrew Dunstan wrote:
> >
> >
> > On 08/21/2018 04:49 PM, Andres Freund wrote:
> > > On 2018-08-21 11:09:15 -0700, Joshua D. Drake wrote:
> > > > On 08/21/2018 11:06 AM, Andrew Dunstan wrote:
> > > > >
> > > > >
Hi
On Thu, Aug 16, 2018 at 6:30 PM, Andres Freund wrote:
> Hi,
>
> On 2018-08-16 14:28:25 +0200, Peter Eisentraut wrote:
> > On 16/08/2018 01:06, Andres Freund wrote:
> > > So it looks like msvc 2013 might be the relevant requirement.
> >
> > According to my research (completely untested in prac
On Tue, Aug 21, 2018 at 11:16 PM, Tom Lane wrote:
> Andres Freund writes:
>> On 2018-08-21 13:29:20 -0400, Tom Lane wrote:
>>> We've got a buildfarm handy that could answer the question.
>>> Let's just stick a test function in there for a day and see
>>> which animals fail.
>
>> I think we pretty
On 2018-08-21 17:58:00 -0400, Andrew Dunstan wrote:
>
>
> On 08/21/2018 04:49 PM, Andres Freund wrote:
> > On 2018-08-21 11:09:15 -0700, Joshua D. Drake wrote:
> > > On 08/21/2018 11:06 AM, Andrew Dunstan wrote:
> > > >
> > > >
> > > > XP at least is essentially a dead platform for us. My anima
On 08/21/2018 04:49 PM, Andres Freund wrote:
On 2018-08-21 11:09:15 -0700, Joshua D. Drake wrote:
On 08/21/2018 11:06 AM, Andrew Dunstan wrote:
XP at least is essentially a dead platform for us. My animals are not
able to build anything after release 10.
I wouldn't think XP should even be
On 2018-08-21 11:09:15 -0700, Joshua D. Drake wrote:
> On 08/21/2018 11:06 AM, Andrew Dunstan wrote:
> >
> >
> >
> > XP at least is essentially a dead platform for us. My animals are not
> > able to build anything after release 10.
>
> I wouldn't think XP should even be on our list anymore. Mic
On 2018-08-21 14:06:18 -0400, Andrew Dunstan wrote:
>
>
> On 08/21/2018 01:31 PM, Andres Freund wrote:
> > Hi,
> >
> > On 2018-08-21 13:29:20 -0400, Tom Lane wrote:
> > > Peter Eisentraut writes:
> > > > So, does anyone with Windows build experience want to comment on this?
> > > > The proposal
On 08/21/2018 11:06 AM, Andrew Dunstan wrote:
XP at least is essentially a dead platform for us. My animals are not
able to build anything after release 10.
I wouldn't think XP should even be on our list anymore. Microsoft hasn't
supported it in 4 years.
JD
--
Command Prompt, Inc. || ht
On 08/21/2018 01:31 PM, Andres Freund wrote:
Hi,
On 2018-08-21 13:29:20 -0400, Tom Lane wrote:
Peter Eisentraut writes:
So, does anyone with Windows build experience want to comment on this?
The proposal is to desupport anything older than (probably) MSVC 2013,
or alternatively anything th
On 08/21/2018 01:46 PM, Tom Lane wrote:
> Andres Freund writes:
>> On 2018-08-21 13:29:20 -0400, Tom Lane wrote:
>>> We've got a buildfarm handy that could answer the question.
>>> Let's just stick a test function in there for a day and see
>>> which animals fail.
>
>> I think we pretty much know
Hi,
On 2018-08-21 13:46:10 -0400, Tom Lane wrote:
> Andres Freund writes:
> > On 2018-08-21 13:29:20 -0400, Tom Lane wrote:
> >> We've got a buildfarm handy that could answer the question.
> >> Let's just stick a test function in there for a day and see
> >> which animals fail.
>
> > I think we
Andres Freund writes:
> On 2018-08-21 13:29:20 -0400, Tom Lane wrote:
>> We've got a buildfarm handy that could answer the question.
>> Let's just stick a test function in there for a day and see
>> which animals fail.
> I think we pretty much know the answer already, anything before 2013
> will
Hi,
On 2018-08-21 13:29:20 -0400, Tom Lane wrote:
> Peter Eisentraut writes:
> > So, does anyone with Windows build experience want to comment on this?
> > The proposal is to desupport anything older than (probably) MSVC 2013,
> > or alternatively anything that cannot compile the attached test fi
Peter Eisentraut writes:
> So, does anyone with Windows build experience want to comment on this?
> The proposal is to desupport anything older than (probably) MSVC 2013,
> or alternatively anything that cannot compile the attached test file.
We've got a buildfarm handy that could answer the ques
On 16/08/2018 15:00, Andres Freund wrote:
>> According to my research (completely untested in practice), you need
>> 2010 for mixed code and declarations and 2013 for named initialization
>> of structs.
>>
>> I wonder what raising the msvc requirement would imply for supporting
>> older Windows ver
On 08/16/2018 12:05 PM, Andres Freund wrote:
Hi,
On 2018-08-16 11:41:30 -0400, Tom Lane wrote:
Andres Freund writes:
But enabling C99 support triggered a somewhat weird failure on
protosciurus (also solaris, but gcc)
https://buildfarm.postgresql.org/cgi-bin/show_log.pl?nm=protosciurus&dt=2
Hi,
On 2018-08-16 11:41:30 -0400, Tom Lane wrote:
> Andres Freund writes:
> > But enabling C99 support triggered a somewhat weird failure on
> > protosciurus (also solaris, but gcc)
> > https://buildfarm.postgresql.org/cgi-bin/show_log.pl?nm=protosciurus&dt=2018-08-16%2013%3A37%3A46
>
> > It det
Andres Freund writes:
> But enabling C99 support triggered a somewhat weird failure on
> protosciurus (also solaris, but gcc)
> https://buildfarm.postgresql.org/cgi-bin/show_log.pl?nm=protosciurus&dt=2018-08-16%2013%3A37%3A46
> It detects C99 support successfully via -std=gnu99 but then fails
> s
Hi,
On 2018-08-16 04:18:59 -0700, Andres Freund wrote:
> Besides gaur, I'm also awaiting casteroides' results. The latter
> definitely does support C99, but I'm not sure autconf pushes hard
> enough. I think every other relevant animal has reported back.
Casteroides wasn't a problem, -D_STDC_C99
Hi,
On 2018-08-16 14:28:25 +0200, Peter Eisentraut wrote:
> On 16/08/2018 01:06, Andres Freund wrote:
> > So it looks like msvc 2013 might be the relevant requirement.
>
> According to my research (completely untested in practice), you need
> 2010 for mixed code and declarations and 2013 for name
On 16/08/2018 14:30, Andres Freund wrote:
> Hi,
>
> On 2018-08-16 14:26:07 +0200, Peter Eisentraut wrote:
>> On 16/08/2018 13:18, Andres Freund wrote:
>>> checking for ccache gcc option to accept ISO C99... unsupported
>>>
>>> I suspect that's because of the '-ansi' flag in CFLAGS, not because
Hi,
On 2018-08-16 14:26:07 +0200, Peter Eisentraut wrote:
> On 16/08/2018 13:18, Andres Freund wrote:
> > checking for ccache gcc option to accept ISO C99... unsupported
> >
> > I suspect that's because of the '-ansi' flag in CFLAGS, not because
> > the compiler is incapable of actually sup
On 16/08/2018 01:06, Andres Freund wrote:
> So it looks like msvc 2013 might be the relevant requirement.
According to my research (completely untested in practice), you need
2010 for mixed code and declarations and 2013 for named initialization
of structs.
I wonder what raising the msvc requirem
On 16/08/2018 13:18, Andres Freund wrote:
> checking for ccache gcc option to accept ISO C99... unsupported
>
> I suspect that's because of the '-ansi' flag in CFLAGS, not because
> the compiler is incapable of actually supporting C99.
-ansi is equivalent to -std=c90. If we make the switch
On 2018-08-16 01:41:34 -0700, Andres Freund wrote:
> I've pushed a minimal version adding the C99 test.
So, we get:
* lotsa animals, unsurprisingly, showing C99 work without any flags.
checking for ccache gcc option to accept ISO C99... none needed
* rhinoceros, nudibranch, grouse, ...:
Hi,
On 2018-08-15 18:31:10 -0400, Tom Lane wrote:
> Andres Freund writes:
> > I think we could get a start by adding that test to configure, without
> > relying on it for now (i.e. keeping mylodon with -Wc99-extensions
> > -Werror=c99-extensions alive). That'd tell us about which machines,
> > be
There's also clang on Windows, which VS apparently supports. With clang
on Windows PG could even make use of GCC/Clang C extensions :^)
On Thu, Aug 16, 2018 at 11:06 AM, Andres Freund wrote:
> On 2018-08-16 10:54:01 +1200, Thomas Munro wrote:
>> Really? I am not an MSVC user but I had the impression that their C
>> mode (/TC or files named .c) was stuck on C89/C90 as a matter of
>> policy, as Herb Sutter explained here (though ma
I wrote:
> BTW, independently of whether to back-patch, it strikes me that what
> we ought to do in HEAD (after applying this) is to just assume we have
> C99-compliant behavior, and rip out the baroque logic in psnprintf
> and appendPQExpBufferVA that tries to deal with pre-C99 snprintf.
Here's a
Hi,
On 2018-08-16 10:54:01 +1200, Thomas Munro wrote:
> Really? I am not an MSVC user but I had the impression that their C
> mode (/TC or files named .c) was stuck on C89/C90 as a matter of
> policy, as Herb Sutter explained here (though maybe the situation has
> changed since then):
They revis
Thomas Munro writes:
> Really? I am not an MSVC user but I had the impression that their C
> mode (/TC or files named .c) was stuck on C89/C90 as a matter of
> policy, as Herb Sutter explained here (though maybe the situation has
> changed since then):
> https://herbsutter.com/2012/05/03/reader-
On Thu, Aug 16, 2018 at 10:40 AM, Andres Freund wrote:
> Hi,
>
> On 2018-08-15 18:31:10 -0400, Tom Lane wrote:
>> Andres Freund writes:
>> > On 2018-08-15 18:13:59 -0400, Tom Lane wrote:
>> >> Experimenting here says that even reasonably modern gcc's won't take
>> >> declarations-inside-for witho
Hi,
On 2018-08-15 18:31:10 -0400, Tom Lane wrote:
> Andres Freund writes:
> > On 2018-08-15 18:13:59 -0400, Tom Lane wrote:
> >> Experimenting here says that even reasonably modern gcc's won't take
> >> declarations-inside-for without "--std=c99" or such.
>
> > I think autoconf's magic knows abo
Andres Freund writes:
> On 2018-08-15 18:13:59 -0400, Tom Lane wrote:
>> Experimenting here says that even reasonably modern gcc's won't take
>> declarations-inside-for without "--std=c99" or such.
> I think autoconf's magic knows about most of that:
> — Macro: AC_PROG_CC_C99
Ah, of course. Wh
Hi,
On 2018-08-15 18:13:59 -0400, Tom Lane wrote:
> Experimenting here says that even reasonably modern gcc's won't take
> declarations-inside-for without "--std=c99" or such. No idea about
> other compilers. So we'd have a little bit of work to do on
> configuration before we could open the flo
Andres Freund writes:
> On 2018-08-15 14:05:29 -0400, Tom Lane wrote:
>> Still want to argue for no backpatch?
> I'm a bit confused. Why did you just backpatch this ~two hours after
> people objected to the idea? Even if it were during my current work
> hours, I don't even read mail that often i
Andres Freund writes:
> On 2018-08-15 15:57:43 -0400, Tom Lane wrote:
>> I'd always thought this was only in C++. This alone might be a sufficient
>> reason to drop C89 compiler support ...
> It's also IIRC reasonably widely supported from before C99. So, for the
> sake of designated initializer
On 2018-08-15 14:05:29 -0400, Tom Lane wrote:
> I wrote:
> > Meh --- the hazards of back-patching seem to me to be more hypothetical
> > than the benefits. Still, I seem to be in the minority, so I withdraw
> > the proposal to back-patch.
>
> Actually, after digging around a bit, I'm excited abou
Hi,
On 2018-08-15 15:57:43 -0400, Tom Lane wrote:
> I'd always thought this was only in C++. This alone might be a sufficient
> reason to drop C89 compiler support ...
It's also IIRC reasonably widely supported from before C99. So, for the
sake of designated initializers, for loop scoping, snpri
David Steele writes:
> On 8/15/18 3:18 PM, Tom Lane wrote:
>> I do dearly miss the ability to easily limit the scope of a loop's
>> control variable to just the loop, eg
>> for (int i = 0; ...) { ... }
>> But AFAIK that's C++ not C99.
> This works in C99 -- and I'm a really big fan.
It does
On 8/15/18 3:18 PM, Tom Lane wrote:
> Andrew Dunstan writes:
>> On 08/15/2018 12:17 PM, Tom Lane wrote:
>>> Robert Haas writes:
Personally, I'd prefer to
continue avoiding // comments and intermingled declarations of
variables and code on grounds of style and readability.
>
>>> ..
On 08/15/2018 03:18 PM, Tom Lane wrote:
FWIW, the issue I've got with what C99 did is that you can narrow the
*start* of the scope of a local variable easily, but not the *end* of
its scope, which seems to me to be solving at most half of the problem.
To solve the whole problem, you end up ne
Andrew Dunstan writes:
> On 08/15/2018 12:17 PM, Tom Lane wrote:
>> Robert Haas writes:
>>> Personally, I'd prefer to
>>> continue avoiding // comments and intermingled declarations of
>>> variables and code on grounds of style and readability.
>> ... which I agree with.
> A decade or so ago I
On 08/15/2018 12:17 PM, Tom Lane wrote:
Robert Haas writes:
Personally, I'd prefer to
continue avoiding // comments and intermingled declarations of
variables and code on grounds of style and readability.
... which I agree with.
A decade or so ago I would have strongly agreed with you
David Steele writes:
> On 8/15/18 12:17 PM, Tom Lane wrote:
>> Robert Haas writes:
>>> Personally, I'd prefer to
>>> continue avoiding // comments and intermingled declarations of
>>> variables and code on grounds of style and readability.
>> ... which I agree with.
> We already have -Wdeclarat
I wrote:
> Meh --- the hazards of back-patching seem to me to be more hypothetical
> than the benefits. Still, I seem to be in the minority, so I withdraw
> the proposal to back-patch.
Actually, after digging around a bit, I'm excited about this again.
There are only a couple dozen places in our
On 8/15/18 12:17 PM, Tom Lane wrote:
> Robert Haas writes:
>
>> Personally, I'd prefer to
>> continue avoiding // comments and intermingled declarations of
>> variables and code on grounds of style and readability.
>
> ... which I agree with.
We already have -Wdeclaration-after-statement to pre
Alvaro Herrera writes:
> On 2018-Aug-15, Robert Haas wrote:
>> Back-patching seems a bit aggressive to me considering that the danger
>> is hypothetical.
> That was my first thought too, and my preferred path would be to make
> this master-only and only consider a backpatch later if we find some
Robert Haas writes:
> On Wed, Aug 15, 2018 at 11:52 AM, Andres Freund wrote:
>> We could just mandate C99, more generally.
>>
>> /me goes and hides in a bush.
> It's hard to believe that would cost much.
I think we have done that, piece by piece, where it was actually buying us
something. In
Hi,
On 2018-08-15 12:01:28 -0400, Robert Haas wrote:
> On Wed, Aug 15, 2018 at 11:52 AM, Andres Freund wrote:
> > We could just mandate C99, more generally.
> >
> > /me goes and hides in a bush.
>
> It's hard to believe that would cost much.
Yea.
> Personally, I'd prefer to continue avoiding
Greetings,
* Andres Freund (and...@anarazel.de) wrote:
> On 2018-08-15 11:41:46 -0400, Tom Lane wrote:
> > BTW, independently of whether to back-patch, it strikes me that what
> > we ought to do in HEAD (after applying this) is to just assume we have
> > C99-compliant behavior, and rip out the bar
On Wed, Aug 15, 2018 at 11:52 AM, Andres Freund wrote:
> We could just mandate C99, more generally.
>
> /me goes and hides in a bush.
It's hard to believe that would cost much. Personally, I'd prefer to
continue avoiding // comments and intermingled declarations of
variables and code on grounds
On 2018-Aug-15, Robert Haas wrote:
> On Tue, Aug 14, 2018 at 7:28 PM, Tom Lane wrote:
> > I'm almost tempted to think that the reasons above make this a
> > back-patchable bug fix. Comments?
>
> No objections to changing the behavior. Have you checked whether
> there are any noticeable perform
Hi,
On 2018-08-15 11:41:46 -0400, Tom Lane wrote:
> BTW, independently of whether to back-patch, it strikes me that what
> we ought to do in HEAD (after applying this) is to just assume we have
> C99-compliant behavior, and rip out the baroque logic in psnprintf
> and appendPQExpBufferVA that trie
Robert Haas writes:
> On Tue, Aug 14, 2018 at 7:28 PM, Tom Lane wrote:
>> I'm almost tempted to think that the reasons above make this a
>> back-patchable bug fix. Comments?
> No objections to changing the behavior. Have you checked whether
> there are any noticeable performance consequences?
On Tue, Aug 14, 2018 at 7:28 PM, Tom Lane wrote:
> I'm almost tempted to think that the reasons above make this a
> back-patchable bug fix. Comments?
No objections to changing the behavior. Have you checked whether
there are any noticeable performance consequences?
Back-patching seems a bit ag
82 matches
Mail list logo
