[GRASS-user] Clarifying use of postgres/postgis

[Rich Shepard]

On Sat, 15 Aug 2020, Micha Silver wrote:

> But again, don't confuse - this is NOT PostGIS, and GRASS does not
> need/use PostGIS for geometry. GRASS geometry is always independent of any
> external geospatial format.

Micha,

Thanks for clarifying; I must have mis-understood what I read. I assumed the
geometry was kept by GRASS and didn't know why PostGIS was mentioned ... and
I don't recall just where I read all this.

> It's the other way around: When you export GRASS map layers, you can, as
> you know, choose to save out to several formats: shp, Geopackage (the
> current default) or to PostGIS. PostGIS is the best choice when you need
> multiuser access to the geospatial data. But you point out that you're the
> only user, so why would you need the overhead of PostGIS?

Ah, so. I don't.

> To repeat, you can set the default for saving attribute tables to
> PostgreSQL, but do not try to save a GRASS layer to PostGIS in the same
> database! That will definitely lead to trouble. If you want/need a PostGIS
> instance for some reason independent of GRASS, then keep it totally
> separated from GRASS. i.e. at least in a separate schema or even separate
> database.

No, I want the attribute data in postgres so I need to learn to make that
the default.

> The main reasons for choosing PostgreSQL as your database backend would be
>
> 1. to allow fancy SQL queries on the database tables
> 2. huge, complex data tables or triggers
> 3. multiuser access to the attribute tables

My reason is keeping these data in the same format as other project data.

> But keep in mind that the default sqlite database is quite powerful, and you 
> would have to look very deeply to find a PostgreSQL feature that is missing 
> in sqlite.

Yes, I've been using SQlite as long as I have PostgreSQL.

Thanks,

Rich