[GRASS-dev] Re: [GRASS GIS] #1274: PostGIS load with v.in.ogr fails without -t

[GRASS GIS]

#1274: PostGIS load with v.in.ogr fails without -t
------------------------+---------------------------------------------------
 Reporter:  arencambre  |       Owner:  grass-dev@…              
     Type:  defect      |      Status:  new                      
 Priority:  normal      |   Milestone:  6.4.1                    
Component:  Default     |     Version:  6.4.1 RCs                
 Keywords:              |    Platform:  MSWindows 7              
      Cpu:  x86-32      |  
------------------------+---------------------------------------------------

Comment(by mmetz):

 Replying to [ticket:1274 arencambre]:
 > (This problem also happens in 6.4.0.)
 >
 > Given the following command (XXX and YYY replaced with valid values):
 {{{
 > v.in.ogr -o "dsn=PG:dbname=de host=localhost port=5432 user=XXX
 password=YYY
 > sslmode=disable" layer=consistent.master output=master_grass4 --verbose
 }}}
 >
 > The result:
 >
 {{{
 > Over-riding projection check
 > Layer: consistent.master
 > Width for column school_zone set to 255 (was not specified by OGR), some
 strings may be truncated!
 > Width for column vehicle_color set to 255 (was not specified by OGR),
 some strings may be truncated!
 > Width for column offense_location set to 255 (was not specified by OGR),
 some strings may be truncated!
 > Width for column work_zone set to 255 (was not specified by OGR), some
 strings may be truncated!
 > DBMI-Postgres driver error:
 > Cannot connect to Postgres: fe_sendauth: no password
 > supplied
 > Unable to open database <host=localhost,dbname=de> by driver <pg>
 > ERROR: Unable open database <host=localhost,dbname=de> by driver <pg>
 }}}
 >
 > I think the important error is '''fe_sendauth: no password supplied'''.
 It's clearly bogus as the width warnings would not be possible unless the
 database table was read, which means there is in fact a valid password.

 I think the error happens when v.in.ogr wants to connect to the output
 database, which is usually different from the input database specified
 with the dsn option. You can check the current grass database connection
 settings with db.connect -p. A new attribute table would be written to
 this database. If username and password are not specified in pg connection
 settings, you would need to login first with db.login, before you can
 access the database.

 IOW, the dsn option of v.in.ogr has nothing to do with the grass database
 connection settings, but these settings are needed by v.in.ogr to write an
 attribute table.

 Markus M

-- 
Ticket URL: <http://trac.osgeo.org/grass/ticket/1274#comment:1>
GRASS GIS <http://grass.osgeo.org>