From: | Joe Conway <mail(at)joeconway(dot)com> |
---|---|
To: | Bruce Momjian <bruce(at)momjian(dot)us> |
Cc: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Alvaro Herrera <alvherre(at)commandprompt(dot)com>, Peter Eisentraut <peter_e(at)gmx(dot)net>, pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: pg_migrator mention in documentation |
Date: | 2009-07-03 23:03:54 |
Message-ID: | 4A4E8E5A.30302@joeconway.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Bruce Momjian wrote:
> Tom Lane wrote:
>> Alvaro Herrera <alvherre(at)commandprompt(dot)com> writes:
>>> Consistency here is pointless. IIRC the dual method is used in contrib
>>> because people did not trust the PGXS stuff enough to rip the original
>>> Make code out; or maybe because people did not want PGXS to become the
>>> default build method, but they allowed it to be used in contrib as a
>>> test bed that PGXS worked.
>> The main reason contrib still has the alternate method is that PGXS
>> doesn't really work until after you've installed the core build.
>> For modules distributed separately from core, it doesn't seem that
>> exciting to be able to build using the contrib method.
>>
>> Now, having said that, I'm personally interested in being able to build
>> pg_migrator against an uninstalled source tree, because I foresee
>> needing to do that for RPM packaging purposes. But I could easily patch
>> the makefiles if needed to make that happen. I don't think this case
>> should drive the choice of what's the default or common method.
>
> Well, PGXS is now the recommended install method in the pg_migrator
> INSTALL file. What other changes should I make?
Since PGXS does not work under Windows, I think the only way to build
non-contrib extensions on Windows is the contrib way (i.e. place in
contrib folder and use contrib style Makefile).
Joe
From | Date | Subject | |
---|---|---|---|
Next Message | Ron Mayer | 2009-07-04 00:54:17 | Re: First CommitFest: July 15th |
Previous Message | Guillaume Smet | 2009-07-03 22:54:14 | Re: SQL state in log_line_prefix |