Re: moving from contrib to bin

On Sun, Jan 18, 2015 at 10:21 PM, Andres Freund <andres(at)2ndquadrant(dot)com> wrote:
> On 2015-01-18 21:05:29 +0900, Michael Paquier wrote:
>> On Sat, Jan 17, 2015 at 10:08 PM, Andres Freund <andres(at)2ndquadrant(dot)com> wrote:
>> > Observations:
>> > 1) Are we sure it's a good idea to rely on pgxs.mk in src/bin programs?
>
>> Yeah, this seems like a bad dependency, PGXS being made for contrib
>> modules... So corrected in the patch attached (the headers of the
>> Makefiles are improved as well to be consistent with the other
>> utilities, btw there is code duplication in each Makefile if we do not
>> use PGXS stuff in src/bin).
>
> Yes, there's a fair amount of duplication. I do think there's a good
> case for making the Makefiles less redundant, but we should do that in
> all src/bin binaries, and in a separate patch.
Agreed on that. pg_ctl is a good candidate for improvement as well.

>> > 4) I have doubts that it's ok to integrate the tests in src/bin just the
>> > way they were done in contrib.
>> Are you referring to the tests of pg_upgrade?
> Yes.
I am not foreseeing any problems with the way they are done now as
long as they continue to use pg_regress to initialize the cluster.
Perhaps you have something on top of your mind?

>> > 5) Doing the msvc support for all intermediate commits in a separate
>> > commit strikes me as a bad idea. Essentially that makes the split
>> > pretty pointless.
>> > 6) Similarly I'd much rather see the doc movement in the same commit as
>> > the actually moved utility. Then we can start applying this one by one
>> > on whatever we have agreement.
>
>> Well, sure. The split was done just to facilitate review with stuff to
>> be applied directly on top of what Peter already did. And note that I
>> agree as well that everything should be done in a single commit.
>
> I don't think all of the moves should be done in one commit. I'd much
> rather do e.g. all the pg_upgrade stuff in one, and the rest in another.
OK. I am fine with that. pg_upgrade move touches backend code.

Now the remaining point seems to be: do we move pg_standby as well?
Seeing the last emails of this thread the answer would be to let it
end its life happily in contrib/.
--
Michael