| From: | James William Pye <lists(at)jwp(dot)name> | 
|---|---|
| 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-30 23:50:11 | 
| Message-ID: | F30F9B9F-4EBA-4AEE-8D04-0D39C0B6CE46@jwp.name | 
| Views: | Whole Thread | Raw Message | Download mbox | Resend email | 
| Thread: | |
| Lists: | pgsql-hackers | 
On Jan 30, 2010, at 3:36 PM, Ivan Sergio Borgonovo 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.
eh:
jwp(at)torch[]:org/postgresql/git 0% ls /src/build 
pg		pg-nodb-plpy	pg81		pg83		pg85		pg_foreach	py		py31-nodb
pg-nodb		pg80		pg82		pg84		pg90		pgweb		py31
The tricky part is that they tend to multiply. ;)
> Requiring I compile a private version of postgres[1]
> increase the cost of development unreasonably,
That install of PG that you're using will *probably not* have debugging information.
Now, granted, you might not need PG with debugging for some problems, but chances are that you'll come across one (or two or fifty or so) where you *will* need it.
I'd suggest using a private install for dev as well. Enable debugging and casserts, and make sure your ulimit's allow core dumps.
I'm not sure if pgxs can do what you want or not, but using a private prefix works well enough for me.
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Euler Taveira de Oliveira | 2010-01-31 00:25:32 | Re: development setup and libdir | 
| Previous Message | Robert Haas | 2010-01-30 23:32:58 | Re: development setup and libdir |