Re: moving from contrib to bin

From: Michael Paquier <michael(dot)paquier(at)gmail(dot)com>
To: Peter Eisentraut <peter_e(at)gmx(dot)net>
Cc: Andres Freund <andres(at)2ndquadrant(dot)com>, Alvaro Herrera <alvherre(at)2ndquadrant(dot)com>, pgsql-hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: moving from contrib to bin
Date: 2015-03-12 00:21:32
Message-ID: CAB7nPqR9tDZJXoXW0bg=UgmM46q2ux7LtY8nq+ap1O61mW1ceQ@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Thu, Mar 12, 2015 at 8:50 AM, Peter Eisentraut wrote:
> On 3/11/15 10:00 AM, Andres Freund wrote:
>> On 2015-03-10 22:06:37 -0300, Alvaro Herrera wrote:
>>> I don't think we care one bit whether these modules use pgxs, at least
>>> not currently. If we find any issues later on, it should be an easy fix
>>> anyway.
>>
>> I personally find it quite ugly to use pgxs for stuff in
>> src/bin. pgxs.mk says:
>> # This file contains generic rules to build many kinds of simple
>> # extension modules. You only need to set a few variables and include
>> # this file, the rest will be done here.
>
> Let's get history straight. pgxs was not initially an external
> extension building framework. It was a refactoring of our own internal
> makefile rules, because a lot of code under contrib had the same rules
> copy-and-pasted. It was only much later that it was rebranded for
> external use. It's debatable why it wasn't expanded to also be used in
> src/bin/, but I attribute that to a combination of boredom, complicated
> special cases under src/bin/, less frequent additions under src/bin/,
> and said rebranding -- not because it would have been a bad idea.
>
> You effectively suggest that we are not allowed to use our own code and
> propose that we undo that refactoring, and then what? I'll just
> resubmit the same patch from 2001 to refactor it again?
>
>> I don't object at all to introducing more generic rules for src/bin, but
>> that seems like a separate task. And one that should be done right not
>> just use some convenient hack. And you can't tell me that
>> +NO_PGXS = 1
>> +include $(top_srcdir)/src/makefiles/pgxs.mk
>> isn't a hack...
>
> Well, that's unfortunate, but I'd rather live with one line of hack for
> a while that I can easily fix later, instead of writing completely new
> makefiles from scratch. Who is going to want to debug those, by the
> way? The turnaround time for makefile changes in this project is one
> month per line, because we can't get anything reviewed across all
> platforms any faster.

Well, TBH, I am on Andres' and Tom's side for this stuff. It feels
that using a PGXS rule like that is a trap for circular dependencies
and I am sure we do not want that. I think as well that we should
involve all the other utilities in src/bin if we do such a
refactoring, so that's definitely a next step, not this one obviously.

Attached is a series of patch rebased on current HEAD, there were some
conflicts after perl-tidying the refactoring patch for MSVC. Note that
this series still uses PGXS in the Makefiles, I am fine to update them
if necessary once this matter is set (already did this stuff upthread
with a previous version).
--
Michael

Attachment Content-Type Size
0001-Move-pg_archivecleanup-from-contrib-to-src-bin.patch text/x-diff 7.9 KB
0002-Move-pg_xlogdump-from-contrib-to-src-bin.patch text/x-diff 10.6 KB
0003-Move-pgbench-from-contrib-to-src-bin.patch text/x-diff 8.7 KB
0004-Move-pg_test_fsync-from-contrib-to-src-bin.patch text/x-diff 6.8 KB
0005-Move-pg_test_timing-from-contrib-to-src-bin.patch text/x-diff 6.6 KB
0006-Integrate-pg_upgrade_support-module-into-backend.patch text/x-diff 26.2 KB
0007-Move-pg_upgrade-from-contrib-to-src-bin.patch text/x-diff 20.7 KB

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Peter Eisentraut 2015-03-12 00:38:59 Re: Turning off HOT/Cleanup sometimes
Previous Message Kohei KaiGai 2015-03-11 23:54:17 Re: One question about security label command