[GRASSLIST:327] Re: [GRASS5] grass and postgis

marcos boullón magán marcosboullon at gmail.com
Thu Mar 23 05:20:28 EST 2006


Last question about this, I promise. In GRASS 6.1 cvs,
grass6/db/base/Makefile has commented out the creation of db.createdb,
db.dropdb and db.databases commands (maybe because they are function
calls to unimplemented code in grass/lib/db/stubs/). But GRASS roadmap
for 6.x series shows "DBMS support (done)".

Does it mean that there will be no support to create new databases
from GRASS (not only new tables as now)? And if functionality is in
progress but not finished, will it have PostGIS (out-of-the-box)
support?

Thanks a lot (for spending your time with the newbies),

M.


(BTW. FYI. Sometimes I get confused expressing myself in english. When
in doubt, I was quering for the most obvious piece of info. This means
that yesterday I wasn't saying "I consider that pg.postgisdb is
redundant; please remove it!" but "I don't understand what
pg.postgisdb does". It wasn't a critizism to any command, I remark.)

2006/3/22, Markus Neteler <neteler at itc.it>:
> > Second. Can someone describe the goal of pg.postgisdb command in a few
> > lines? I can see it creates a plpgsql language and a
> > plpgsql_call_handler() function in a (yet PostGIS-aware?) database
> > linked to plpgsql.so system library. Doesn't it duplicate the PostGIS
> > installation process step "createlang plpgsql yourdatabase && psql -f
> > lwpostgis.sql -d your_database"? And doesn't it mix badly local tools
> > (my grass local install) and remote services (my remote postgresql +
> > postgis install)? (execution checks for a postgis install available
> > locally to pg.postgisdb command, but postgis should be only installed
> > in remote server where postgresql is).
>
> I vote for removing pg.postgisdb. It's just an outdated thing, sort
> of leftover from GRASS 5.1 times.
>
> Markus
>

--
-- marcos boullón magán




More information about the grass-user mailing list