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: (view raw, whole thread or download thread mbox)
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

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-2017 The PostgreSQL Global Development Group