[pgrouting-dev] pgRouting 2.0 Update

[Stephen Woodbridge]

On 3/17/2013 2:56 PM, Sandro Santilli wrote:
> On Sun, Mar 17, 2013 at 01:02:12PM -0400, Stephen Woodbridge wrote:
>
>> The last couple of days has been spent on building a simple test
>> infrastructure and a few trivial test cases.
>
> Good work !

Thanks, I'm trying to evolve our tree into something that is more 
sustainable long term and better supports collaboration. We will see how 
well that works out.

I would really like to get around to hacking the code, but it seems that 
we need to get the infrastructure in place and it is an incredible 
amount of work.

>
>> This probably needs to be
>> made smarter so we can test out of the build tree. I'll need to
>> think about that.

One thing I found that might improve my perl test-runner is 
Test::Postgresql this doesn't solve the problem you were addressing 
below, but I have a thought on how to work around those issues.

> Note it'd currently be impossible to test with the "CREATE EXTENTION"
> mechanism (no way to load an extension from outside the systemwide
> directory).

I just read the thread you started on pgsql-hackers about this issue 
last year. It seems that extension are version wide rather than database 
wide, because the current system assume everything is store in a 
versioned directory tree.

So if you build postgresql from src you can set the PREFIX to something 
like ~/pgN.N which would give us our private version install tree, as a 
regular user so it does not try to overwrite system files. I think you 
should then be able to install your staging code into this tree, start 
this database and test in this environment. This might require a little 
customizing of the things but it should allow you to have multiple 
versions each in their own tree that you can startup via a test script, 
run some tests, and shutdown. There probably needs to be some cleanup 
scripts to remove staged files so your environment doesn't get cruft 
buildup over time. This also might facilitate running postgresql in the 
gdb to catch server crashes and get a backtrace.

I have not tried this but it would be the direction I would pursue. I 
guess something similar could also be done with the system installation, 
but that assumes that it is not getting used for other stuff on a 
multi-use machine like most of my servers.

Any thoughts on this?

Are there other developers/users that would be interested in researching 
this and reporting back.