PostGIS load with v.in.ogr fails without -t

[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.

If I run the same query with a -t, it works fine, but then I get no attributes which isn't what I wanted.

[mmetz]

Replying to 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

[arencambre]

db.connect -p returns this:

driver:pg
database:host=localhost,dbname=de
schema:
group:

So it's trying to connect to the same database.

This is a fresh install of GRASS 6.4.0, and I have never adjusted any database connection settings. All I have done database-related is issue the v.in.ogr command.

Since db.connect -p apparently it picked up host=localhost,dbname=de from v.in.ogr , shouldn't it also get the user id and password?

[mmetz]

Replying to arencambre:

db.connect -p returns this:

> driver:pg
> database:host=localhost,dbname=de
> schema:
> group:

So it's trying to connect to the same database.

This is a fresh install of GRASS 6.4.0, and I have never adjusted any database connection settings. All I have done database-related is issue the v.in.ogr command.

Weird. In your other post at the user ml, the grass database connection was the standard dbf connetion. Is this a fresh install of 6.4.0 or of 6.4.1?

Since db.connect -p apparently it picked up host=localhost,dbname=de from v.in.ogr , shouldn't it also get the user id and password?

db.connect should not pick up anything from v.in.ogr dsn=. In fact, whatever is specified in the dsn option should be completely ignored by grass because it is the duty of the OGR library to cope with the dsn option. At least in the v.in.ogr source code, the dsn option is passed as is, without any checks, to the OGR library. In theory, it could be that the wxGUI is doing something with the dsn option and accidentally changes the default database connection. That would be a bug.

Regarding current 6.4.1, are you using the new wxGUI dialog (File->Import vector data->Common import formats) or the original command dialog which you get when clicking that button at the bottom of the new dialog?

Markus M

[arencambre]

Is this a fresh install of 6.4.0 or of 6.4.1?

Sorry for my delayed response. I tried with fresh installs of 6.4.0-1 and 6.4.1 RC1. Got the same result either way. I did not configure anything related to a DBF file.

Regarding current 6.4.1, are you using the new wxGUI dialog (File->Import vector data->Common import formats) or the original command dialog which you get when clicking that button at the bottom of the new dialog?

With 6.4.0-1, I was using the command dialog. In 6.4.1, I think I was using the same dialog, although it was enhanced and had a multi-line command entry with autocomplete.

[arencambre]

Looks like the milestone was missed.