From: Tom Lane <tgl@sss.pgh.pa.us>
To: Stephen Frost <sfrost@snowman.net>
Cc: Robert Haas <robertmhaas@gmail.com>
Cc: pgsql-hackers@postgresql.org <pgsql-hackers@postgresql.org>
Cc: Piotr Stefaniak <postgres@piotr-stefaniak.me>
Subject: Re: Preliminary results for proposed new pgindent implementation
Date: Fri, 19 May 2017 11:22:54 -0400
Message-ID: <29626.1495207374@sss.pgh.pa.us> (raw)
In-Reply-To: <20170519150526.GX3151@tamriel.snowman.net>
References: <30527.1495162840@sss.pgh.pa.us>
<CA+TgmoamXhAoKY+pPSfGiu=3q6u-+1EOksdPimGS8YuqNuaSYQ@mail.gmail.com>
<26654.1495203668@sss.pgh.pa.us>
<20170519150526.GX3151@tamriel.snowman.net>
List-Unsubscribe: <mailto:majordomo@postgresql.org?body=unsub%20pgsql-hackers>
Stephen Frost <sfrost@snowman.net> writes:
> * Tom Lane (tgl@sss.pgh.pa.us) wrote:
>> Yes, moving the goalposts on ease-of-use is an important consideration
>> here. What that says to me is that we ought to pull FreeBSD indent
>> into our tree, and provide Makefile support that makes it easy for
>> any developer to build it and put it into their PATH. (I suppose
>> that means support in the MSVC scripts too, but somebody else will
>> have to do that part.)
> I'm not a huge fan of this, however. Do we really need to carry around
> the FreeBSD indent in our tree? I had been expecting that these changes
> would eventually result in a package that's available in the common
> distributions (possibly from apt/yum.postgresql.org, at least until it's
> in the main Debian-based and RHEL-based package systems). Are you
> thinking that we'll always have to have our own modified version?
I certainly would rather that our version matched something that's under
active maintenance someplace. But it seems like there are two good
arguments for having a copy in our tree:
* easy accessibility for PG developers
* at any given time we need to be using a specific "blessed" version,
so that all developers can get equivalent results. There's pretty much
no chance of that happening if we depend on distro-provided packages,
even if those share a common upstream.
We've had reasonably decent luck with tracking the tzcode/tzdata packages
as local copies, so I feel like we're not taking on anything unreasonable
if our model is that we'll occasionally (not oftener than once per year)
update our copy to recent upstream and then re-indent using that.
> What about perltidy itself..? We don't include that in our tree either.
Not being much of a Perl guy, I don't care one way or the other about
perltidy. Somebody else can work on that if it needs work.
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
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Reply to all the recipients using the --to and --cc options:
reply via email
To: pgsql-hackers@postgresql.org
Cc: tgl@sss.pgh.pa.us, sfrost@snowman.net, robertmhaas@gmail.com, postgres@piotr-stefaniak.me
Subject: Re: Preliminary results for proposed new pgindent implementation
In-Reply-To: <29626.1495207374@sss.pgh.pa.us>
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox