Re: development setup and libdir

From: Dimitri Fontaine <dfontaine(at)hi-media(dot)com>
To: Ivan Sergio Borgonovo <mail(at)webthatworks(dot)it>
Cc: pgsql-hackers(at)postgresql(dot)org
Subject: Re: development setup and libdir
Date: 2010-01-31 19:48:19
Message-ID: m23a1m9hto.fsf@hi-media.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Hi,

Ivan Sergio Borgonovo <mail(at)webthatworks(dot)it> writes:
> 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...

Untrue. Get the sources with git clone, them
./configure --prefix=~/pgsql/master --enable-debug --enable-cassert
make
make install

Now you can add ~/pgsql/master to your PATH, initdb then pg_ctl start,
and use PGXS. All will work just fine, and against a *devel* env. Not a
production one. That's a clear *bonus*.

> 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.

I think you're mixing up the development needs with the packaging
ones. You have to keep separating them even when doing both.

> 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.

You want pre-packaged stuff, that does not mean you develop them on
production servers. Virtual Machines and chroot etc are cheap.

> still I think my need isn't that weird and could lower the entry
> point for many developers quite a bit.

Well you're only missing non-root make install with *packaged*
PostgreSQL. As it stands, the 2 options are not compatible.

But I fail to see how much it's a burden now that it's easy to develop
on a dedicated *virtual* machine, e.g.

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

Development environment and production one are different. You seem to be
wanting to ease the development on production environment. I'm not
convinced this is a good way of approaching the problem.

Regards,
--
dim

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Stefan Kaltenbrunner 2010-01-31 19:48:25 Re: Re: [COMMITTERS] pgsql: Augment WAL records for btree delete with GetOldestXmin() to
Previous Message Tom Lane 2010-01-31 19:44:07 Re: Hot Standby and VACUUM FULL