On Sun, Jan 18, 2015 at 10:21 PM, Andres Freund <and...@2ndquadrant.com> wrote: > On 2015-01-18 21:05:29 +0900, Michael Paquier wrote: >> On Sat, Jan 17, 2015 at 10:08 PM, Andres Freund <and...@2ndquadrant.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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers