Re: pg_migrator mention in documentation - Mailing list pgsql-hackers

From Joe Conway
Subject Re: pg_migrator mention in documentation
Date
Msg-id 4A4E8E5A.30302@joeconway.com
Whole thread Raw
In response to Re: pg_migrator mention in documentation  (Bruce Momjian <bruce@momjian.us>)
Responses Re: pg_migrator mention in documentation  (Bruce Momjian <bruce@momjian.us>)
List pgsql-hackers
Bruce Momjian wrote:
> Tom Lane wrote:
>> Alvaro Herrera <alvherre@commandprompt.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



pgsql-hackers by date:

Previous
From: Guillaume Smet
Date:
Subject: Re: SQL state in log_line_prefix
Next
From: Ron Mayer
Date:
Subject: Re: First CommitFest: July 15th