[GRASS-dev] [GRASS GIS] #2193: v.in.ogr does not handle columns named 2D_lenght and 3D_lenght

GRASS GIS trac at osgeo.org
Sun Feb 9 00:32:49 PST 2014


#2193: v.in.ogr does not handle columns named 2D_lenght and 3D_lenght
------------------------------------------------------------+---------------
 Reporter:  wenzeslaus                                      |       Owner:  grass-dev@…              
     Type:  defect                                          |      Status:  new                      
 Priority:  minor                                           |   Milestone:  7.0.0                    
Component:  Vector                                          |     Version:  svn-trunk                
 Keywords:  v.in.ogr, r.in.gdal, import, database, columns  |    Platform:  All                      
      Cpu:  All                                             |  
------------------------------------------------------------+---------------

Comment(by hamish):

 Hi,

 IIUC, column names starting with a number are not SQL compliant so won't
 work in grass. e.g. if a column was called '3e' (or perhaps just '3')
 should the sql select statement treat it like a number or a column?
 there's the same common problem with sql reserved keywords used as column
 names + v.in.ogr, with the same solution: either continue to ban them, or
 go through all the code and add quoting to every place it needs it.

 we've had similar discussions about allowing vector maps to use non-sql
 compliant names as they used to in grass 5 and older. a solution there is
 to either cleanse them for the table names and adjust db.connect/dbln as
 needed, or again spend a bunch of time finding everywhere that needs
 quoting.

 in the 2D, 3D, -> xD case, perhaps the code should insert the "x" instead
 of replacing (if it's flagged for starting with a number), other non-
 compatible chars would still need to be x'd though. And remember that dbf
 limits to 10 char column names, so if adding an "x" at the beginning you
 need to check if it is needed to remove one from the end. (even if dbf
 isn't the default anymore it still needs to be supported)


 regards,
 Hamish

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



More information about the grass-dev mailing list