#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 |
------------------------+---------------------------------------------------
(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.
#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.
#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 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?
#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 [comment:2 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?
#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 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.