<br><br><div class="gmail_quote">On Mon, Apr 12, 2010 at 12:21 PM, Ben Madin <span dir="ltr"><<a href="mailto:lists@remoteinformation.com.au">lists@remoteinformation.com.au</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
OK<br>
<div class="im"><br>
On 12/04/2010, at 10:03 , Nicholas Bower wrote:<br>
<br>
> 2. Dump just this separate data schema using pg_dump -Fc -N <schema><br>
<br>
</div>I think here you mean -n?, but it's six of one and half a dozen of the other. I routinely use different schema's for different aspects of the database, hence easier to just exclude one.<br></blockquote><div>
<br></div><div>Yes -n you're right.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<div class="im"><br>
> I note your solution of the separate schema using default path hack - interesting that this works (assume you change the search path for all db updater roles).<br>
<br>
</div>I'm not sure what you mean by this question, sorry. I do change the search_path for the database -<br>
<br>
        ALTER database SET search_path TO data, reference, users, gis;<br>
<br>
if that is what you are referring to?<br></blockquote><div><br></div><div>Yep that's it - you're changing the search path not just of the restore, but all roles using that database ongoing so they can find the postgis functions.  When I started experimenting with Postgis back in 2003, I couldn't get it to work so ever since I've used public schema for postgis.  I should have tried harder ;)</div>
<div><br></div><div>Btw have you restored your backups from scratch before and found them to work?</div><div><br></div></div>