-----Original Message----- From: Moritz Lennert [mailto:mlenn...@club.worldonline.be] Sent: 21. oktober 2016 11:30 >> However, it seems that for raster maps more special characters are >> legal and also v.in.ogr uses layer names from the original data >> source which can cause conflicts in SQL DB backends... > >That's why the option of not having table names identical to map names >might be more flexible, but it creates a bit of confusion when people >assume that identity of names.
Having map names and table names - as far as possible - identical is very convenient. I would not change that. > >> Maybe legal file names, column and table handling is something to >> re-consider for GRASS 8? > >Sure. > >How much of a problem is there really, though ? What do you propose >needs changing ? > >Moritz No idea how much of a problem that is in praxis. Table or column name issues pop up here and there and are usually fixed with a simple workaround. Users can always cause trouble for themselves when managing attribute data through db.execute and the SQL which is supported by their backend. The latter often allows for things which can cause problems for GRASS modules. Furthermore, one can of course also get data where column names are not compliant with GRASS standards.... The current handling of column and table names regarding special characters, upper/lower case is not really consistent, which is untypical for GRASS (at least from my experience). However, e.g. quoting all SQL identifiers would require significant changes (as quoting is also backend depending) and involves likely quite some work. So, it is probably not worth changing anything. I shall have a look at the documentation, if limitations of SQL in GRASS should be made more explicit there... Kind regards, Stefan _______________________________________________ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
