Re: pg_xlogdump

From: Peter Eisentraut <peter_e(at)gmx(dot)net>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: Andres Freund <andres(at)2ndquadrant(dot)com>, Dimitri Fontaine <dimitri(at)2ndQuadrant(dot)fr>, Jeff Janes <jeff(dot)janes(at)gmail(dot)com>, Alvaro Herrera <alvherre(at)2ndquadrant(dot)com>, Pg Hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: pg_xlogdump
Date: 2013-02-26 17:02:48
Message-ID: 512CEAB8.9010400@gmx.net
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On 2/26/13 11:45 AM, Tom Lane wrote:
> But let's not break the cases that do work. One
> of the functions of contrib/ is to serve as models/skeletons for
> external modules. If we pull out the "useless" PGXS support then we'll
> just be making it that much harder to copy a contrib module and start
> doing something useful.

Well, this is exactly the problem. Because of this skeleton idea, most
external extension modules do not build unless you set USE_PGXS=1 before
building, because they think that they live in contrib by default, which
is completely bizarre and user-unfriendly.

We could have an actual example or skeleton whose purpose is to teach
extension authors. The actual contrib module makefiles should just do
their job and don't pretend to teach things that are misguided and/or
don't work.

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Robert Haas 2013-02-26 17:19:17 Re: auto_explain WAS: RFC: Timing Events
Previous Message Michael Meskes 2013-02-26 16:58:21 Re: "COPY foo FROM STDOUT" and ecpg