Skip site navigation (1) Skip section navigation (2)

Re: pg_migrator mention in documentation

From: "Kevin Grittner" <Kevin(dot)Grittner(at)wicourts(dot)gov>
To: "Alvaro Herrera" <alvherre(at)commandprompt(dot)com>, "Peter Eisentraut" <peter_e(at)gmx(dot)net>
Cc: "Bruce Momjian" <bruce(at)momjian(dot)us>,<pgsql-hackers(at)postgresql(dot)org>
Subject: Re: pg_migrator mention in documentation
Date: 2009-07-02 18:46:30
Message-ID: 4A4CBA3602000025000282F2@gw.wicourts.gov (view raw or flat)
Thread:
Lists: pgsql-hackers
Alvaro Herrera <alvherre(at)commandprompt(dot)com> wrote: 
 
> I wonder why we have two ways at all (I'm not counting the stuff
> about copying it to contrib because it seems pointless).  The other
> day I was looking at orafce code in pgfoundry, and at clearxlogtail
> too IIRC, and they both had the "ifdef USE_PGXS" stuff in the
> Makefile.  I wonder why.  Why not just rip the "ifdef" line and the
> non-PGXS code, and just use PGXS always?
 
Well, most of our database servers wind up with multiple builds of
PostgreSQL, and we find it is less error-prone for the non-programmer
DBAs to expand a tarball under such a directory from the normal build
(for the appropriate version) and make it there.  There also seemed
some possibility that clearxlogtail would be accepted into the
distribution as a contrib module, so I was trying to have it ready to
go, should that happen.
 
As an aside, our function for extracting text from a PDF in a bytea
didn't work right when I tried to build it using the PGXS the other
day.  I moved the directory into our PostgreSQL build location and
built it the other way and it worked.  I haven't tracked down why, but
it leaves me leery of carving out the form which worked for me.  (When
you don't really understand something, you resort to superstitious
ritual....)
 
-Kevin

In response to

pgsql-hackers by date

Next:From: Peter EisentrautDate: 2009-07-02 18:59:08
Subject: Autoconf 2.63
Previous:From: Chris BrowneDate: 2009-07-02 18:40:57
Subject: Re: 8.5 development schedule

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group