Re: development setup and libdir - Mailing list pgsql-hackers

On Sat, 30 Jan 2010 18:32:58 -0500
Robert Haas <robertmhaas@gmail.com> wrote:

> On Sat, Jan 30, 2010 at 5:36 PM, Ivan Sergio Borgonovo
> <mail@webthatworks.it> wrote:
> >> For development purposes you would be far better off building a
> >> private version of postgres (with configure --prefix=/path) and
> >> using its pgxs to build, install and test your module.

> > That's pretty expensive.

> How?  I rebuild the backend five or ten times a day when doing PG
> work.  Doesn't seem like a big deal.

I'm not scared about compile time.
But considering that what it's really missing between what I need
and what I get is renaming a file... it's just a pain I've to set up
a whole new instance of postgres, install the whole source etc...
I think most of you are core developers or people that really invest
and have invested a reasonably large % of your time in postgres
development.

It makes sense to have a complete development environment[1].

But well again... considering I'm a "rename" away from being able to
compile and test an extension with my user privileges... it's just a
pity it doesn't work that way out of the box.

Another scenario could be I could just svn update on a staging box,
compile there and then move everything to production easier.
Not every shop is a multimillion dollars enterprise that can afford
a dev/staging/production box for every version of postgres it is
using.
If you don't need to squeeze out every cpu cycle in a production box
you may be happy with a pre-packaged postgres.

I admit my approach may be naïve considering the build system has to
work on many architecture/OSes... so the problems that have to be
solved just to install somewhere else may be more complicated but
still I think my need isn't that weird and could lower the entry
point for many developers quite a bit.

I've spent some time greping through makefile to see if I could
propose a patch. From my point of view passing a parameter at make
install time would make things much better. Another thing I had to
tweak was the path in in.sql (that one should be taken from a
parameter too).

Ideally once you write the source code... where/how you're going to
use it should just depend on parameters passed at make time.

Now my main concern is making my C code work in a reasonably decent
development environment. I hope if I'll ever succeed to take this
project to an end before being forced to take care of other stuff,
my code or my documented experience will come useful to others.
Trying to understand how pgxs works may be my next effort, right now
I'll use a workaround since just being able to build and load my
modules wherever I want is going to make *my* development experience
much manageable.

I still think that *my* need is not that weird.

Now let's see if I can come up with a useful module. At least one
other user of postgres has shown interest on what I was trying to do
on pgsql-general.

Next step in my postgres awareness may be using peg. Thanks Greg.

[1] and yeah I'll need dbg symbols but that's going to happen later.

--
Ivan Sergio Borgonovo
http://www.webthatworks.it