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 |
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 |