[postgis-users] Schema support in loader/dumper
strk at keybit.net
Fri Mar 19 11:12:25 PST 2004
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.
> > 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...
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.
More information about the postgis-users