v.in.ogr doesn't use information from dblogin file about external PostgreSQL server

[hemeybo]

To import data from an external PostgreSQL server with v.in.ogr, I want to use the dblogin file created with db.login with ip-address, user name and password for the login on the external server. Login on the server is working fine, since db.tables lists all tables on the server. Using db.databases with the location flag works also fine, listing all available databases on the external server. If I try to use v.in.ogr with the server login information in the dsn string (with password written in plain text!!), everything is doing ok. But since I don't want to write my password visible for everybody every time I use the import function, I think, it should be possible to use v.in.ogr with the login information of the dblogin file.

The error message, I recieve is the following:

"DBMI-PostgreSQL driver error: Unable to connect to Postgres: could not connect to server: No such file or directory

Is the server running locally and accepting connections on Unix domain socket "/var/run/postgresql/.s.PGSQL.5432"?

DBMI-PostgreSQL driver error: Unable to connect to Postgres: could not connect to server: No such file or directory

Is the server running locally and accepting connections on Unix domain socket "/var/run/postgresql/.s.PGSQL.5432"?

ERROR: Unable to list databases. Try to define correct connection settings

by db.login."

This occurs to be the same error message as if I use db.databases without the location flag.

For me, this somehow looks like the db.databases function is not working properly together with the dblogin file.

The same problem occurs with the use of v.external

[martinl]

This has been fixed in trunk, could you test it please? BTW, when using default DB connection, you can leave datasource string empty, see ​http://grass.osgeo.org/grass71/manuals/v.in.ogr.html#default-connection-settings-as-datasource-%28postgresql-only%29

[hemeybo]

Unfortunately, there is not much improvement. The error moved on from "Unable to list databases" to "Unable to open data source" with the correct connection details. Here the new error message:

v.in.ogr dsn=PG: layer=bfn.nw_buk1000 output=nw_buk1001 ERROR 1: PQconnectdb failed. could not connect to server: No such file or directory

Is the server running locally and accepting connections on Unix domain socket "/var/run/postgresql/.s.PGSQL.5432"?

ERROR: Unable to open data source

<PG:dbname=host=134.110.32.101,dbname=gis>

It seems like the dsn is not created properly - the first "dbname=" is wrong, in my opinion.

[martinl]

Replying to hemeybo:

ERROR: Unable to open data source

<PG:dbname=host=134.110.32.101,dbname=gis>

It seems like the dsn is not created properly - the first "dbname=" is wrong, in my opinion.

please post here the commands in which you set up the connection settings (db.connect and db.login).

[hemeybo]

here the commands for the connection settings:

db.connect driver=pg database="host=134.110.32.101,dbname=gis" db.login user=username pass=password

[martinl]

I have implemented experimental support for db.login settings to v.in.ogr and v.external in r67510. There is unfortunately a duplicated code (dsn.c) which would be probably good to move to Vlib to avoid code duplication. We will need similar code for v.out.ogr, v.out.postgis and v.external.out. These modules already contain a duplicated code (list layers). It would make sense to move this duplicated code to the library (a new one, eg. libgrass_gdal) or to Vlib.

Similar situation for r.in.gdal, r.external and r.external.out. From this point of view a new library which would provide listing layers (both raster and vector), setting datasource would make more sense.

What do you think? Better ideas?

[martinl]

This issue will be hardly solved in 7.0. Changing milestone to 7.2.

[mlennert]

What is the status of this issue ? Should this be dealt with before moving into 7.2 hard freeze, or should we move the milestone to 7.4 ?

[mlennert]

Is this a duplicate of #3167 ?

[martinl]

Replying to mlennert:

Is this a duplicate of #3167 ?

Seems to be like that. Taking liberty to close the ticket. Feel free to reopen if needed.