On Mon, Sep 12, 2016 at 1:47 AM, Tom Lane wrote:
> Looks reasonable to me, we'll soon see what the buildfarm thinks.
Thanks for the commit. I am seeing green statuses on the buildfarm.
--
Michael
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your sub
Michael Paquier writes:
> On Sun, Sep 11, 2016 at 1:03 AM, Tom Lane wrote:
>> It might accidentally fail to fail as-is, but likely it would be better
>> not to be pushing garbage paths into extraincludes and extralibs when
>> some of those options aren't set.
> Right, we need to correct somethin
On Sun, Sep 11, 2016 at 1:03 AM, Tom Lane wrote:
> It might accidentally fail to fail as-is, but likely it would be better
> not to be pushing garbage paths into extraincludes and extralibs when
> some of those options aren't set.
Right, we need to correct something here. But this block does not
Michael Paquier writes:
> Thanks. I was a bit too lazy to look at the history to get this piece
> of history out... And so the code that is presently in the MSVC
> scripts should have been updated at the same time as those
> compilations have been relaxed, but it got forgotten on the way I
> guess
Michael Paquier writes:
> Thanks. I was a bit too lazy to look at the history to get this piece
> of history out... And so the code that is presently in the MSVC
> scripts should have been updated at the same time as those
> compilations have been relaxed, but it got forgotten on the way I
> guess
On Thu, Sep 8, 2016 at 10:04 PM, Tom Lane wrote:
> The core code has never used xslt at all.
Yes.
> Some quick digging in the git
> history suggests that contrib/xml2 wasn't very clean about this before
> 2008:
> [...]
> Both of those fixes postdate our native-Windows port, though I'm not sure
>
Michael Paquier writes:
> On Thu, Sep 8, 2016 at 9:39 PM, Magnus Hagander wrote:
>> Pretty sure this goes back to *our* XML support requiring both. As in you
>> couldn't turn on/off xslt independently, so the "xml requires xslt" comment
>> is that *our* xml support required both.
>>
>> This may
On Thu, Sep 8, 2016 at 2:53 PM, Michael Paquier
wrote:
> On Thu, Sep 8, 2016 at 9:39 PM, Magnus Hagander
> wrote:
> > Pretty sure this goes back to *our* XML support requiring both. As in you
> > couldn't turn on/off xslt independently, so the "xml requires xslt"
> comment
> > is that *our* xml
On Thu, Sep 8, 2016 at 9:39 PM, Magnus Hagander wrote:
> Pretty sure this goes back to *our* XML support requiring both. As in you
> couldn't turn on/off xslt independently, so the "xml requires xslt" comment
> is that *our* xml support required both.
>
> This may definitely not be true anymore, a
On Thu, Sep 8, 2016 at 9:27 PM, Tom Lane wrote:
> Michael Paquier writes:
>> But I don't understand the reason behind such a restriction to be
>> honest because libxml2 does not depend on libxslt. The contrary is
>> true: libxslt needs libxml2.
>
> Right.
>
>> Note as well that libxml2 does depen
On Thu, Sep 8, 2016 at 2:27 PM, Tom Lane wrote:
> Michael Paquier writes:
> > But I don't understand the reason behind such a restriction to be
> > honest because libxml2 does not depend on libxslt. The contrary is
> > true: libxslt needs libxml2.
>
> Right.
>
Pretty sure this goes back to *our
Michael Paquier writes:
> But I don't understand the reason behind such a restriction to be
> honest because libxml2 does not depend on libxslt. The contrary is
> true: libxslt needs libxml2.
Right.
> Note as well that libxml2 does depend on ICONV though.
Hm, is that true either? I don't see a
Hi all,
Looking at the MSVC scripts for some stuff I have noticed the following thing:
if ($options->{xml})
{
if (!($options->{xslt} && $options->{iconv}))
{
die "XML requires both XSLT and ICONV\n";
}
}
But I don't understand the reason behind such
13 matches
Mail list logo
