Hi,
Ivan Sergio Borgonovo <mail@webthatworks.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
makeinstall
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