VS 2015 support in src/tools/msvc

On 03/03/16 15:02, Michael Paquier wrote:

Hi all,

Microsoft provides a set of VMs that one can use for testing and
Windows 10 is in the set:
https://dev.windows.com/en-us/microsoft-edge/tools/vms/windows/
I have grabbed one and installed the community version of Visual
Studio 2015 so I think that I am going to be able to compile Postgres
with VS2015 with a bit of black magic.

My goal is double:
1) As far as things have been discussed, VS2015 is making difficult
the compilation of Postgres, particularly for locales. So I'd like to
see what are the problems behind that and see if we can patch it
properly. This would facilitate the integration of cmake as well for
Windows.

The locale problem is that:
a) the MS crt headers are broken for this particular part due to
unfinished refactoring, even their msvcrt sources don't compile with
them, if you read them it's obvious they forgot to put one variable in
the struct
b) we are using somewhat legacy API there that's internally implemented
as hacks over the new API (string parsing and generation and stuff is
happening there)
c) the non-legacy API works only on Vista+ and does not support the old
locale names (which is why the legacy api that is written on top of this
has to do the string parsing and generation)

To me the least bad solution for MSVC 2015 and codepage detection seemed
to use the new API when possible (GetLocaleInfoEx and friends) and fall
back to our old string parsing that we did pre-VC2013 when it's not,
since afaics it works correctly on all the locale names that are not
supported by the new API. It means that MSVC 2015 builds would be Vista+
but I honestly don't see that as big issue given Microsoft's own policy
about old Windows versions.

2) src/tools/msvc stuff has support only up to VS2013. I think that it
would be nice to bump that a bit and get something for 9.5~.

Yeah, we'll also have to do something about perl 5.22 compatibility
there as psed is not included in the core distribution anymore from that
version and we use it to generate one header file IIRC.

So, would there be interest for a patch on the perl scripts in
src/tools/msvc or are they considered a lost cause? Having a look at
the failures could be done with the cmake work, but it seems a bit
premature to me to look at that for the moment, and having support for
VS2015 with 9.5 (support for new versions of VS won a backpatch the
last couple of years) would be a good thing I think.

+1, and I can help (at least review and testing if nothing else).

--
Petr Jelinek http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services

--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

Petr Jelinek <petr@2ndquadrant.com> writes:

On 03/03/16 15:02, Michael Paquier wrote:

So, would there be interest for a patch on the perl scripts in
src/tools/msvc or are they considered a lost cause? Having a look at
the failures could be done with the cmake work, but it seems a bit
premature to me to look at that for the moment, and having support for
VS2015 with 9.5 (support for new versions of VS won a backpatch the
last couple of years) would be a good thing I think.

+1, and I can help (at least review and testing if nothing else).

Yeah. At this point, the earliest the cmake work could land is 9.7,
and TBH I do not think we are committed to landing it at all. So it'd
behoove us to fix at least HEAD, and probably older branches too,
to work with up-to-date MSVC.

regards, tom lane

--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

Tom Lane wrote:

Yeah. At this point, the earliest the cmake work could land is 9.7,
and TBH I do not think we are committed to landing it at all. So it'd
behoove us to fix at least HEAD, and probably older branches too,
to work with up-to-date MSVC.

In that case we should probably add the configure check for IPC::Run
that was proposed in another thread.

--
�lvaro Herrera http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services

--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

Alvaro Herrera <alvherre@2ndquadrant.com> writes:

Tom Lane wrote:

Yeah. At this point, the earliest the cmake work could land is 9.7,
and TBH I do not think we are committed to landing it at all. So it'd
behoove us to fix at least HEAD, and probably older branches too,
to work with up-to-date MSVC.

In that case we should probably add the configure check for IPC::Run
that was proposed in another thread.

Yeah, agreed. I opposed it at the time because I thought we might be
considering cmake conversion for 9.6. But now that that's missed the
final 9.6 commitfest, we'd better operate on the assumption that it's
not landing anytime soon.

regards, tom lane

--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

On 03/03/2016 09:02 AM, Michael Paquier wrote:

Hi all,

Microsoft provides a set of VMs that one can use for testing and
Windows 10 is in the set:
https://dev.windows.com/en-us/microsoft-edge/tools/vms/windows/
I have grabbed one and installed the community version of Visual
Studio 2015 so I think that I am going to be able to compile Postgres
with VS2015 with a bit of black magic.

My goal is double:
1) As far as things have been discussed, VS2015 is making difficult
the compilation of Postgres, particularly for locales. So I'd like to
see what are the problems behind that and see if we can patch it
properly. This would facilitate the integration of cmake as well for
Windows.
2) src/tools/msvc stuff has support only up to VS2013. I think that it
would be nice to bump that a bit and get something for 9.5~.

So, would there be interest for a patch on the perl scripts in
src/tools/msvc or are they considered a lost cause? Having a look at
the failures could be done with the cmake work, but it seems a bit
premature to me to look at that for the moment, and having support for
VS2015 with 9.5 (support for new versions of VS won a backpatch the
last couple of years) would be a good thing I think.

I am not holding my breath on cmake. Until we have something pretty
solid on that front I'm going to assume it's not happening. If we're
going to support VS2015 (and I think we should) then it should be
supported for all live branches if possible. I'm assuming the changes
would be pretty localized, at least in src/tools/msvc, and adding a new
compile shouldn't break anything with existing compilers.

cheers

andrew

--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

On Thu, Mar 3, 2016 at 6:18 PM, Andrew Dunstan <andrew@dunslane.net> wrote:

On 03/03/2016 09:02 AM, Michael Paquier wrote:

Hi all,

Microsoft provides a set of VMs that one can use for testing and
Windows 10 is in the set:
https://dev.windows.com/en-us/microsoft-edge/tools/vms/windows/
I have grabbed one and installed the community version of Visual
Studio 2015 so I think that I am going to be able to compile Postgres
with VS2015 with a bit of black magic.

My goal is double:
1) As far as things have been discussed, VS2015 is making difficult
the compilation of Postgres, particularly for locales. So I'd like to
see what are the problems behind that and see if we can patch it
properly. This would facilitate the integration of cmake as well for
Windows.
2) src/tools/msvc stuff has support only up to VS2013. I think that it
would be nice to bump that a bit and get something for 9.5~.

So, would there be interest for a patch on the perl scripts in
src/tools/msvc or are they considered a lost cause? Having a look at
the failures could be done with the cmake work, but it seems a bit
premature to me to look at that for the moment, and having support for
VS2015 with 9.5 (support for new versions of VS won a backpatch the
last couple of years) would be a good thing I think.

I am not holding my breath on cmake. Until we have something pretty solid
on that front I'm going to assume it's not happening. If we're going to
support VS2015 (and I think we should) then it should be supported for all
live branches if possible. I'm assuming the changes would be pretty
localized, at least in src/tools/msvc, and adding a new compile shouldn't
break anything with existing compilers.

+1.

Definitely do it for HEAD.

Then if it gets backpatched is going to depend on the locality I think. If
it's just the build system then it should be no problem, but I thought
Michael also suggested some API changes. If that's so, then it is going to
depend on how invasive those are. But that part should be done for HEAD
regardless, so it's definitely worth the effort to figure out exactly what
it involves.

--
Magnus Hagander
Me: http://www.hagander.net/
Work: http://www.redpill-linpro.com/

On 03/03/16 18:41, Magnus Hagander wrote:

On Thu, Mar 3, 2016 at 6:18 PM, Andrew Dunstan <andrew@dunslane.net
<mailto:andrew@dunslane.net>> wrote:

On 03/03/2016 09:02 AM, Michael Paquier wrote:

Microsoft provides a set of VMs that one can use for testing and
Windows 10 is in the set:
https://dev.windows.com/en-us/microsoft-edge/tools/vms/windows/
I have grabbed one and installed the community version of Visual
Studio 2015 so I think that I am going to be able to compile
Postgres
with VS2015 with a bit of black magic.

So, would there be interest for a patch on the perl scripts in
src/tools/msvc or are they considered a lost cause? Having a look at
the failures could be done with the cmake work, but it seems a bit
premature to me to look at that for the moment, and having
support for
VS2015 with 9.5 (support for new versions of VS won a backpatch the
last couple of years) would be a good thing I think.

I am not holding my breath on cmake. Until we have something pretty
solid on that front I'm going to assume it's not happening. If we're
going to support VS2015 (and I think we should) then it should be
supported for all live branches if possible. I'm assuming the
changes would be pretty localized, at least in src/tools/msvc, and
adding a new compile shouldn't break anything with existing compilers.

+1.

Definitely do it for HEAD.

Then if it gets backpatched is going to depend on the locality I think.
If it's just the build system then it should be no problem, but I
thought Michael also suggested some API changes. If that's so, then it
is going to depend on how invasive those are. But that part should be
done for HEAD regardless, so it's definitely worth the effort to figure
out exactly what it involves.

Well the source code does not compile on MSVC2015, the perl changes
needed are really tiny, there is some code that needs changes to work
with 2015, particularly in the locale code-page detection area so it's
definitely not just build system. But I think it should be fairly
localized and fenced by ifdef anyway.

--
Petr Jelinek http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services

--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

On Fri, Mar 4, 2016 at 7:21 AM, Petr Jelinek <petr@2ndquadrant.com> wrote:

Well the source code does not compile on MSVC2015, the perl changes needed
are really tiny, there is some code that needs changes to work with 2015,
particularly in the locale code-page detection area so it's definitely not
just build system. But I think it should be fairly localized and fenced by
ifdef anyway.

Yeah, that's my first impression as well. We should not need any APIs
changes and the changes would be limited to if extra blocks with
_MSC_VER, if that would occur then I definitely agree that patching
only HEAD is the way to go. I'll look at that today and the next
couple of days, let's see what I can get out of it...
--
Michael

--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

On Fri, Mar 4, 2016 at 9:36 AM, Michael Paquier
<michael.paquier@gmail.com> wrote:

Yeah, that's my first impression as well. We should not need any APIs
changes and the changes would be limited to if extra blocks with
_MSC_VER, if that would occur then I definitely agree that patching
only HEAD is the way to go. I'll look at that today and the next
couple of days, let's see what I can get out of it...

So, I have finally been able to set up my environment correctly, and I
am at a stage where I can compile Postgres with VS 2015 thanks to the
patch attached that extends src/tools/msvc to do so. Unsurprisingly,
the first failures detected are related to locales :)

I still need to dig into that in more details. For the time being the
patch attached is useful IMO to plug in VS 2015 with the existing
infrastructure. So if anybody has a Windows environment, feel free to
play with it and dig into those problems. I'll update this thread once
I have a more advanced status.
Regards,
--
Michael

On Fri, Mar 4, 2016 at 3:54 PM, Michael Paquier
<michael.paquier@gmail.com> wrote:

I still need to dig into that in more details. For the time being the
patch attached is useful IMO to plug in VS 2015 with the existing
infrastructure. So if anybody has a Windows environment, feel free to
play with it and dig into those problems. I'll update this thread once
I have a more advanced status.

OK, attached are a set of patches that allowed me to compile Postgres
using VS2015, in more details:
- 0001, as mentioned by Petr upthread, psed is removed from the core
distribution of Perl in 5.22, so when installing ActivePerl it is not
possible to create probes.h, and the code compilation would fail. I
bumped into that so here is a patch. What I am proposing here is to
replace psed by sed, sed being available in MSYS like bison and flex,
so when building using MSVC the environment to set up is normally
already good to go even with this additional dependency. Now, it is
important to mention that probes.h is not part of a source tarball. I
think that we would want probes.h to be part of a source tarball so as
it would be possible to compile the code on Windows using MSVC without
having to install MSYS. I haven't done that in this patch, thoughts on
the matter are welcome.
- 0002, which adds support for VS2015 in src/tools/scripts
- 0003, to address a compilation failure that I bumped into when
compiling ecpg. In src/port, TIMEZONE_GLOBAL and TZNAME_GLOBAL refer
to respectively timezone and tzname, however for win32, those should
be _timezone and _tzname. See here:
https://msdn.microsoft.com/en-us/library/htb3tdkc.aspx
- 0004, which is to address the problem of the missing lc_codepage
from locale.h in src/port/. I have been pondering about the use of
more fancy routines like GetLocaleInfoEx as mentioned by Petr
upthread. However, I think that we had better avoid any kind of
complication and just fall back to the old code path should _MSC_VER

= 1900. We could always reuse lc_codepage if it gets reintroduced in

a future version of VS.

This set of patches is clearly a work-in-progress, but I am at the
point where feedback is welcome, and the code can compile. The issue
wit psed is something I think could be backpatched a bit more than the
VS2015 core patches, support for perl 5.22 happening on all the
supported branches.
Note that I did not bump into the stdbool issues. Note as well that VS
has complained about a couple of warnings. I am attaching them in the
file named VS2015_warnings.txt. Those are quite interesting as well.
--
Michael

Michael Paquier wrote:

- 0001, as mentioned by Petr upthread, psed is removed from the core
distribution of Perl in 5.22, so when installing ActivePerl it is not
possible to create probes.h, and the code compilation would fail. I
bumped into that so here is a patch. What I am proposing here is to
replace psed by sed, sed being available in MSYS like bison and flex,
so when building using MSVC the environment to set up is normally
already good to go even with this additional dependency. Now, it is
important to mention that probes.h is not part of a source tarball. I
think that we would want probes.h to be part of a source tarball so as
it would be possible to compile the code on Windows using MSVC without
having to install MSYS. I haven't done that in this patch, thoughts on
the matter are welcome.

I think the path of least resistance is to change the sed script into a
Perl script. Should be fairly simple ...

--
�lvaro Herrera http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services

--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

On Sat, Mar 5, 2016 at 12:08 AM, Alvaro Herrera
<alvherre@2ndquadrant.com> wrote:

Michael Paquier wrote:

- 0001, as mentioned by Petr upthread, psed is removed from the core
distribution of Perl in 5.22, so when installing ActivePerl it is not
possible to create probes.h, and the code compilation would fail. I
bumped into that so here is a patch. What I am proposing here is to
replace psed by sed, sed being available in MSYS like bison and flex,
so when building using MSVC the environment to set up is normally
already good to go even with this additional dependency. Now, it is
important to mention that probes.h is not part of a source tarball. I
think that we would want probes.h to be part of a source tarball so as
it would be possible to compile the code on Windows using MSVC without
having to install MSYS. I haven't done that in this patch, thoughts on
the matter are welcome.

I think the path of least resistance is to change the sed script into a
Perl script. Should be fairly simple ...

Yes that's possible as well. It would be better to use the same
process for *nix platforms as well.
--
Michael

--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

On 4 March 2016 at 22:23, Michael Paquier <michael.paquier@gmail.com> wrote:

On Fri, Mar 4, 2016 at 3:54 PM, Michael Paquier
<michael.paquier@gmail.com> wrote:

I still need to dig into that in more details. For the time being the
patch attached is useful IMO to plug in VS 2015 with the existing
infrastructure. So if anybody has a Windows environment, feel free to
play with it and dig into those problems. I'll update this thread once
I have a more advanced status.

OK, attached are a set of patches that allowed me to compile Postgres
using VS2015, in more details:
- 0001, as mentioned by Petr upthread, psed is removed from the core
distribution of Perl in 5.22, so when installing ActivePerl it is not
possible to create probes.h, and the code compilation would fail. I
bumped into that so here is a patch. What I am proposing here is to
replace psed by sed, sed being available in MSYS like bison and flex,
so when building using MSVC the environment to set up is normally
already good to go even with this additional dependency.

The assumption here is that we're using msys to provide bison and flex
(probably via msysgit), so adding sed isn't any more intrusive.

I think that's reasonable, but wanted to spell it out since right now msys
isn't actually a dependency of the MSVC builds, just a convenient way to
get some of the dependencies. This still adds a new dependency, but it's
one most people will have anyway. If they're using bison/flex from gnuwin32
or whatever instead they can get sed there too. So +1, sensible.

Now, it is
important to mention that probes.h is not part of a source tarball. I
think that we would want probes.h to be part of a source tarball so as
it would be possible to compile the code on Windows using MSVC without
having to install MSYS. I haven't done that in this patch, thoughts on
the matter are welcome.

That's consistent with how we include the generated scanner and lexer files
etc in the source tarball, so +1.

--
Craig Ringer http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services

On 04/03/16 15:23, Michael Paquier wrote:

OK, attached are a set of patches that allowed me to compile Postgres
using VS2015, in more details:
- 0001, as mentioned by Petr upthread, psed is removed from the core
distribution of Perl in 5.22, so when installing ActivePerl it is not
possible to create probes.h, and the code compilation would fail. I
bumped into that so here is a patch. What I am proposing here is to
replace psed by sed, sed being available in MSYS like bison and flex,
so when building using MSVC the environment to set up is normally
already good to go even with this additional dependency. Now, it is
important to mention that probes.h is not part of a source tarball. I
think that we would want probes.h to be part of a source tarball so as
it would be possible to compile the code on Windows using MSVC without
having to install MSYS. I haven't done that in this patch, thoughts on
the matter are welcome.

I vote for just using sed considering we need flex and bison anyway.

- 0003, to address a compilation failure that I bumped into when
compiling ecpg. In src/port, TIMEZONE_GLOBAL and TZNAME_GLOBAL refer
to respectively timezone and tzname, however for win32, those should
be _timezone and _tzname. See here:
https://msdn.microsoft.com/en-us/library/htb3tdkc.aspx

Yep I hit that one as well, looks good.

- 0004, which is to address the problem of the missing lc_codepage
from locale.h in src/port/. I have been pondering about the use of
more fancy routines like GetLocaleInfoEx as mentioned by Petr
upthread. However, I think that we had better avoid any kind of
complication and just fall back to the old code path should _MSC_VER

= 1900. We could always reuse lc_codepage if it gets reintroduced in

a future version of VS.

Well I am worried that this way we might break existing installs which
means we can't backpatch this. The problem here is that the fallback
code does not support the <language>-<REGION> format which Microsoft
documents everywhere as recommended locale format. The good news is that
our own initdb won't auto-generate those when no locale was specified as
it uses the setlocale() which returns the legacy (and not recommended)
locale names and our fallback code can handle those. But manually set
locales can be a problem.

--
Petr Jelinek http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services

--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

On Sat, Mar 5, 2016 at 1:41 PM, Petr Jelinek <petr@2ndquadrant.com> wrote:

On 04/03/16 15:23, Michael Paquier wrote:

OK, attached are a set of patches that allowed me to compile Postgres
using VS2015, in more details:
- 0001, as mentioned by Petr upthread, psed is removed from the core
distribution of Perl in 5.22, so when installing ActivePerl it is not
possible to create probes.h, and the code compilation would fail. I
bumped into that so here is a patch. What I am proposing here is to
replace psed by sed, sed being available in MSYS like bison and flex,
so when building using MSVC the environment to set up is normally
already good to go even with this additional dependency. Now, it is
important to mention that probes.h is not part of a source tarball. I
think that we would want probes.h to be part of a source tarball so as
it would be possible to compile the code on Windows using MSVC without
having to install MSYS. I haven't done that in this patch, thoughts on
the matter are welcome.

I vote for just using sed considering we need flex and bison anyway.

OK cool, we could go with something else than sed to generate probes.h
but that seems sensible considering that this should definitely be
back-patched. Not sure what the others think about adding a new file
in the source tarball by default though.

- 0003, to address a compilation failure that I bumped into when
compiling ecpg. In src/port, TIMEZONE_GLOBAL and TZNAME_GLOBAL refer
to respectively timezone and tzname, however for win32, those should
be _timezone and _tzname. See here:
https://msdn.microsoft.com/en-us/library/htb3tdkc.aspx

Yep I hit that one as well, looks good.

MinGW would react to that correctly I think. If I look at
mingw/include/timezone.h, both timezone and _timezone are defined. I
would think that this is intentional to declare both there.

- 0004, which is to address the problem of the missing lc_codepage
from locale.h in src/port/. I have been pondering about the use of
more fancy routines like GetLocaleInfoEx as mentioned by Petr
upthread. However, I think that we had better avoid any kind of
complication and just fall back to the old code path should _MSC_VER

= 1900. We could always reuse lc_codepage if it gets reintroduced in

a future version of VS.

Well I am worried that this way we might break existing installs which means
we can't backpatch this. The problem here is that the fallback code does not
support the <language>-<REGION> format which Microsoft documents everywhere
as recommended locale format. The good news is that our own initdb won't
auto-generate those when no locale was specified as it uses the setlocale()
which returns the legacy (and not recommended) locale names and our fallback
code can handle those. But manually set locales can be a problem.

I am open to more fancy solutions if it is possible to get reliably
the codepage in a different way, but I am not sure this is worth the
complication. The pre-VS2012 code has been able to live with that.
--
Michael

--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

Michael Paquier <michael.paquier@gmail.com> writes:

On Sat, Mar 5, 2016 at 1:41 PM, Petr Jelinek <petr@2ndquadrant.com> wrote:

I vote for just using sed considering we need flex and bison anyway.

OK cool, we could go with something else than sed to generate probes.h
but that seems sensible considering that this should definitely be
back-patched. Not sure what the others think about adding a new file
in the source tarball by default though.

AFAIK, sed flex and bison originate from three separate source projects;
there is no reason to suppose that the presence of flex and bison on a
particular system guarantee the presence of sed. I thought the proposal
to get rid of the psed dependence in favor of some more perl code was
pretty sane.

regards, tom lane

--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

On 03/05/2016 12:46 AM, Tom Lane wrote:

Michael Paquier <michael.paquier@gmail.com> writes:

On Sat, Mar 5, 2016 at 1:41 PM, Petr Jelinek <petr@2ndquadrant.com> wrote:

I vote for just using sed considering we need flex and bison anyway.

OK cool, we could go with something else than sed to generate probes.h
but that seems sensible considering that this should definitely be
back-patched. Not sure what the others think about adding a new file
in the source tarball by default though.

AFAIK, sed flex and bison originate from three separate source projects;
there is no reason to suppose that the presence of flex and bison on a
particular system guarantee the presence of sed. I thought the proposal
to get rid of the psed dependence in favor of some more perl code was
pretty sane.

Here is a translation into perl of the sed script, courtesy of the s2p
incarnation of psed:
<https://gist.github.com/adunstan/d61b1261a4b91496bdc6&gt; The sed script
appears to have been stable for a long time, so I don't think we need to
be too concerned about possibly maintaining two versions.

cheers

andrew

--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

On Sat, Mar 5, 2016 at 11:34 PM, Andrew Dunstan <andrew@dunslane.net> wrote:

Here is a translation into perl of the sed script, courtesy of the s2p
incarnation of psed: <https://gist.github.com/adunstan/d61b1261a4b91496bdc6&gt;
The sed script appears to have been stable for a long time, so I don't think
we need to be too concerned about possibly maintaining two versions.

That's 95% of the work already done, nice! If I finish wrapping up a
patch for this issue at least would you backpatch? It would be saner
to get rid of this dependency everywhere I think regarding compilation
with perl 5.22.
--
Michael

--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

On 03/05/2016 01:31 PM, Michael Paquier wrote:

On Sat, Mar 5, 2016 at 11:34 PM, Andrew Dunstan <andrew@dunslane.net> wrote:

Here is a translation into perl of the sed script, courtesy of the s2p
incarnation of psed: <https://gist.github.com/adunstan/d61b1261a4b91496bdc6&gt;
The sed script appears to have been stable for a long time, so I don't think
we need to be too concerned about possibly maintaining two versions.

That's 95% of the work already done, nice! If I finish wrapping up a
patch for this issue at least would you backpatch? It would be saner
to get rid of this dependency everywhere I think regarding compilation
with perl 5.22.

Sure.

cheers

andrew

--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers