[postgis-users] Schema support in loader/dumper

[strk]

On Fri, Mar 19, 2004 at 10:44:06AM -0800, David Blasby wrote:
> strk wrote:
> 
> > On Fri, Mar 19, 2004 at 10:27:19AM -0800, David Blasby wrote:
> > 
> >>>Not so easy. Your best bet is a (data-only)dump/restore.
> >>
> >>I still use the same database I used with one of the original postgis 
> >>version (0.3 - like 2 years ago).  I just overwrite the libpostgis the 
> >>database is pointing to.  MAKE SURE YOU BACK IT UP BEFORE YOU OVERWRITE 
> >>IT.  There are a few risks with doing this, but its a lot easier than a 
> >>full dump-and-restore.
> >>
> >>I'd still recommend the dump-and-restore, but if you want to live with a 
> >>little bit of risk, you should be able to just overwrite libpostgis.so 
> >>with a new version.
> >>
> >>dave
> > 
> > 
> > When plpgsql functions are changed this is not enough.
> > The problem found is about AddGeometryColumn/DropGeometryColumn changes.
> > 
> > Maybe we should provide a postgis_update-<from_ver>-<to_ver>.sql file.
> 
> This sounds like a lot of work.  Perhaps we should just change all the 
> "CREATE FUNCTION ..." clauses to "CREATE OR REPLACE FUNCTION...".  This 
> should work well for everything but the GiST support stuff...
> 
> dave

That would not always work.

For example, if you need to change the return type:

ERROR:  ProcedureCreate: cannot change return type of existing function.
        Use DROP FUNCTION first.

What was wrong with postgis_undef.sql again ?
Functions oid mismatch or just an ordering issue ?

BTW: did people try using postgis_new.sql ? further changes
     in sql files would be easier if we can support CPP generation.
     
--strk;