[GRASS-dev] [GRASS GIS] #3167: db.connect: connection to remote database does not work

[GRASS GIS]

#3167: db.connect: connection to remote database does not work
--------------------------+-----------------------------------
  Reporter:  mlennert     |      Owner:  grass-dev@…
      Type:  defect       |     Status:  new
  Priority:  blocker      |  Milestone:  7.0.5
 Component:  Database     |    Version:  unspecified
Resolution:               |   Keywords:  postgresql db.connect
       CPU:  Unspecified  |   Platform:  Unspecified
--------------------------+-----------------------------------

Comment (by mlennert):

 Replying to [comment:25 martinl]:
 > Replying to [comment:23 martinl]:
 >
 > > Thanks for testing, patch applied in all active branches
 (r69597-r69599)
 >
 > What is missing to downgrade priority at least and don't block 7.0.5
 release?

 There is a fundamental issue about importing data from remote server using
 v.in.ogr. See #comment:21 on part of the details. But looking into the
 code, I see even more weirdness: for some reason, v.in.ogr only looks at
 the default database of a pg db.connect-defined connection. I have no
 idea, why. v.in.ogr should import whatever data is available, even from
 other databases.

 Example (after disabling the condition check mentioned above):

 {{{
 createdb -h myRemoteServer testgrass2
 db.connect driver=pg database=testgrass2
 db.login host=myRemoteHost
 db.tables -p
 }}}

 Everything works, no tables shown. But then:


 {{{
 v.in.ogr input="PG:dbname=testgrass" layer=boundary_county out=bc
 }}}

 with testgrass defined in .grass7/dblogin as

 {{{
 pg|testgrass|||myRemoteServer|
 }}}

 I get (with DEBUG=1)


 {{{
 D1/1: G_set_program_name(): v.in.ogr
 D1/1: Using dsn=PG:dbname=testgrass2 host=myRemoteServer
 ERREUR :Layer <boundary_county> not available
 D1/1: G_set_program_name(): g.gisenv
 }}}

 i.e. it automatically tries to get the table from testgrass2, not
 testgrass.

 This comes from the fact that the name of the database is read as such:


 {{{
 dbname = db_get_default_database_name();
 }}}

 Instead of trying to read the database from the dsn string...

 In other words, it seems that importing data from a remote database in
 v.in.ogr needs to be done using a complete dsn string, even if db.login
 was called. And that this will only work on the command line, not in the
 import wizard. Do you confirm ?

 I guess we could call this a "known limitation" and just release as is, as
 it would need a substantial rewrite which I would like to avoid just
 before a release, but it is confusing to users. So maybe some hint about
 this in the import wizard ?

--
Ticket URL: <https://trac.osgeo.org/grass/ticket/3167#comment:26>
GRASS GIS <https://grass.osgeo.org>