so when running my script everything went well except that when i run "psql --version" it still runs the 8.3.2 version... so to do psql (9.2.4) i have to indicate the full path to pgsql9.2.4/bin/psql .. any idea on how to fix this?
On Thu, Jul 4, 2013 at 4:07 PM, Racine, Sylvain <[email protected]>wrote: > The postgis.sql is a part of the restore process. Because you'll make > hard upgrade of PostGIS, you have to use Perl script postgis_restore.pl. > This script removes old PostGIS functions from your backup and installs the > new ones in the new database. Then, you have to give the path of > postgis.sql (or lwpostgis.sql) when you call postgis_restore.pl on > command line. > > I'm not really fan of the new procedure using "CREATE EXTENSION postgis". > It's an automatic process enabled in PostgreSQL 9.1 and more. With this > procedure, you have to use PostGIS who is embedded with PostgreSQL package. > I encountered earlier some errors when I tried to install PostGIS using > this procedure on a Windows box. But, using the old procedure I described > above, I had the complete control of the installation and I always got a > functionnal database, even with PostgreSQL 9.2. > > Regard > > Sylvain Racine > > > Le 2013-07-04 13:06, Marcos Cano a écrit : > > well i guess while installing and making the postgis i installed it > against the 9.2.4 (with this : "./configure > --with-pgconfig=/usr/local/pgsql9.2.4/bin/pg_config" ) > > the postgis.sql you mention is to create a spatially enabled database? or > is it part of the restore process? > > and yes im using the full path to the command to do everything. > > thank you very much i really appreciate it > > > On Thu, Jul 4, 2013 at 9:51 AM, Racine, Sylvain <[email protected]>wrote: > >> You have to use pg_dump version 8.3.2 to backup your database,e.g. the >> same version of your source database. To restore, use the Perl script and >> postgis.sql given with Postgis 2.0.4. This script calls pg_dump command. >> It must be pg_dump version 9.2.4, e.g. your destination database version. >> Use "pg_dump --version" to know the version of your command. >> >> You seem use 2 differents versions of PostgreSQL and PostGIS on the same >> computer. To get a particular version of a command, type the whole path of >> the command. >> >> Regard >> >> Sylvain Racine >> >> Le 2013-07-04 10:07, Marcos Cano a écrit : >> >> what version of pg_dump should i use?... i tried the 8..3.2 and i think >> it works, but trying the suggested one, wich is the latest (9.2.4) seems >> just to not work properly because it does not dump my entire database (i >> assume is because of the mismatch of postgis versions) >> >> >> On Wed, Jul 3, 2013 at 12:00 PM, Paragon Corporation <[email protected]> wrote: >> >>> Yes (custom dump of 8.3.2 + pgis, create new postgis 2.0.4 in 9.2.4 >>> and restore backup) is the recommended way. 9.2.4 + 1.5.8 are borderline >>> compatible so I would avoid that mix and if your ultimate goal is to go to >>> 2.0, 1.5.8 requires a hard upgrade anyway so not worth the hassle. >>> >>> ------------------------------ >>> *From:* [email protected] [mailto: >>> [email protected]] *On Behalf Of *Marcos Cano >>> *Sent:* Wednesday, July 03, 2013 10:43 AM >>> *To:* [email protected] >>> *Subject:* [postgis-users] postgres and postgis upgrade >>> >>> So I'm trying to upgrade Postgres and postgis.. My current versions >>> are 8.3.2 and 1.3 respectively. And trying to upgrade to postgis 2.0.4 and >>> Postgres 9.2.4 >>> >>> I've been trying a lot of options like:hard upgrade of postgis to >>> 1.5.8 in the Postgres 8.3 ( as I'm sure that version of postgis is >>> compatible with Postgres 8.3 and 9.2.4) >>> Then installing postgres 9.2.4 + postgis 1.5.8 and do a pg_upgrade and >>> finally do a hard upgrade of postgis to 2.0.4 in the postgres 9.2.4 >>> installation. It seems to work until an error happened during the >>> pg_upgrade >>> >>> Your installation contains the "name" data type in user tables. This >>> data type changed its internal alignment between your old and new clusters >>> so this cluster cannot currently be upgraded. You can remove the problem >>> tables and restart the upgrade. >>> >>> So I tried another option but I don't know if this will work. Here's >>> my idea: >>> >>> >>> >>> Do a custom dump of the DB in Postgres 8.3.2 + pgis 1.3 . >>> >>> Install 9.2.4 with postgis 2.0.4 >>> And do a restore with perl script included in the postgis binary folder >>> (perl utils/postgis_restore.pl) >>> >>> do you think it will work? >>> >>> _______________________________________________ >>> postgis-users mailing list >>> [email protected] >>> http://lists.osgeo.org/cgi-bin/mailman/listinfo/postgis-users >>> >>> >> >> >> _______________________________________________ >> postgis-users mailing >> [email protected]http://lists.osgeo.org/cgi-bin/mailman/listinfo/postgis-users >> >> >> >> _______________________________________________ >> postgis-users mailing list >> [email protected] >> http://lists.osgeo.org/cgi-bin/mailman/listinfo/postgis-users >> >> > > > _______________________________________________ > postgis-users mailing > [email protected]http://lists.osgeo.org/cgi-bin/mailman/listinfo/postgis-users > > > > _______________________________________________ > postgis-users mailing list > [email protected] > http://lists.osgeo.org/cgi-bin/mailman/listinfo/postgis-users > >
_______________________________________________ postgis-users mailing list [email protected] http://lists.osgeo.org/cgi-bin/mailman/listinfo/postgis-users
