<div dir="ltr"><div><div><div><div><br>On Wed, May 17, 2017 at 5:23 PM, Moritz Lennert <<a href="mailto:mlennert@club.worldonline.be">mlennert@club.worldonline.be</a>> wrote:<br>><br>> On 17/05/17 15:18, Markus Metz wrote:<br>>><br>>> On Wed, May 17, 2017 at 3:09 PM, Martin Landa <<a href="mailto:landa.martin@gmail.com">landa.martin@gmail.com</a><br>>> <mailto:<a href="mailto:landa.martin@gmail.com">landa.martin@gmail.com</a>>> wrote:<br>>>> Connection string can be provided as fully<br>>>> qualified. But also stored connections (via db.login) should be also<br>>>> taken into account. Martin<br>><br>><br>> That is something else, i.e. do we want to create more convenience.<br><br></div>Stored connections should only be taken into account if the current GRASS database connection uses PostgreSQL. The default is SQLite3. A corresponding test appears too late, the damage is already done.<br><br></div>Stored GRASS connection settings could only be used if some OGR PostGIS settings are missing. Instead, the current implementation 1) changes user-supplied parameters, 2) discards user-supplied parameters.<br><br></div>I have fixed relbr72 in r71096.<br><br></div>Markus M<br><div><div><div><div><br>><br>>><br>>> db.login is used for database access where GRASS reads/writes attribute<br>>> tables, right?<br>>><br>>> Why should these settings be used for OGR input? With v.in.ogr, OGR<br>>> input can be anything, and OGR input has nothing to do with where GRASS<br>>> creates a new attribute table. It is not clear why OGR should take into<br>>> account GRASS db settings. Obviously this only causes confusion.<br>><br>><br>> I agree with Markus here. db.connect/db.login settings should IMHO not be (ab)used for read access to DBs.<br>><br>> I would, therefore, plead for a separate approach as already mentioned (either db specific as in v.in.postgis, or generic in a v.in.db (I know this name is already taken by an existing module with different functionality) which might make it easier to define database connections and possible allow the storage of connection parameters.<br>><br>> Currently, selecting "Database" in the import wizard also only works for database that are on localhost. It would be great if information such as host, database, login, and password could be passed to the wizard. Maybe a specific v.in.db type module could help with that ?<br>><br>> Moritz<br>><br></div></div></div></div></div>