Re: pgAgent: C++ Port - Patch Review

Am Donnerstag, 19. September 2013, 13:34:47 schrieb Dave Page:
> On Tue, Sep 17, 2013 at 1:59 PM, Linreg <linreg(at)gmx(dot)net> wrote:
> > Hi Dave,
> >
> >
> >
> > Connection Pooling:
> >
> > okay. I will reimplementing the connection pool.
> >
> > Am Sonntag, 15. September 2013, 15:02:03 schrieb Dave Page:
> >> > > Another problem that I've noticed is that you've unconditionally
> >> > >
> >> > >
> >> > >
> >> > > changed the logging format to be pipe delimited. This is also not
> >> > >
> >> > >
> >> > >
> >> > > acceptable as part of this patch, and should be discussed and
> >> > >
> >> > >
> >> > >
> >> > > implemented separately. At minimum, this would need to be a
> >> > >
> >> > >
> >> > >
> >> > > configurable behaviour change, and by default, I would want it to
> >> > >
> >> > >
> >> > >
> >> > > implement standard (comma delimited) CSV, not a pipe delimited
> >> > >
> >> > >
> >> > >
> >> > > version.
> >> >
> >> > okay. i change this feature to configurable behaviour.
> >> >
> >> >
> >> >
> >> > By default logging will be as before.
> >> >
> >> >
> >> >
> >> > can i add an commandline parameter for this?
> >> >
> >> >
> >> >
> >> > is it than acceptable?
> >>
> >> I think so - but please do that as a separate patch. We don't like to
> >> mixup
> >>
> >> multiple changes in the same patch/commit as it's harder to find issues
> >> or
> >>
> >> review the history in the future.
> >
> > okay. I will make it so.
> >
> >> > Okay, thats a problem.
> >> >
> >> >
> >> >
> >> > I use features from c++11 standard like "atomic" and "thread"
> >> >
> >> >
> >> >
> >> > My suggestion:
> >> >
> >> >
> >> >
> >> > the Pure-C++-Version is is for newer OS / Compiler suits and not
> >> > backward
> >> >
> >> > compatible (relating compiler / c++ version)
> >> >
> >> >
> >> >
> >> > Is the way a possible?
> >>
> >> Not really, as it requires maintenance of 2 code branches until we can
> >>
> >> completely deprecate the old wxWidgets code. That's why PostgreSQL itself
> >>
> >> is extremely conservative about what they'll support. We're not nearly as
> >>
> >> bad as that, but we do need to carry on supporting RHEL 5 and similarly
> >>
> >> aged OSs for a while.
> >
> > I examine whether the use of the boost lib is possible. it should.
> >
> > I think they has a better backward compatibility.
> >
> > Please can you review this for me by
> > http://www.boost.org/development/tests/release/developer/statechart.html
> >
> > you know better than i the version of supported compiler / plattforms.
>
> They have a limited list of platforms there, but FYI, RHEL 5 ships
> with Boost 1.41.0, so if that works, we're probably OK.

Please have an look to this Page
https://access.redhat.com/support/policy/updates/errata/

RHEL5 will be supported until 2017 or with extended support 2020!
you realy want to wait another 4 or 7 years and use old libs and compiler?
Is it not better to make an static linked version or to open a second branch (the
number of patches is very low)?

nonetheless i will try to compile it with boost-feature from Boost 1.41.0.
i must remove the atomic-feature. this should be not a problem.

Thomas Steffen