[GRASS5] 5.1: map/table name restrictions due to SQL

[Glynn Clements]

John A. Preston wrote:

> > Yes, that could be possible solution, but then you get different name 
> > for table and vector. Problem is that to access data outside GRASS
> > (OOffice, pgaccess,...), user must have encode/decode routines in his head,
> > which doesn't seem to be user friendly enough.
> 
> Yes, that's true. But you could (hopefully) provide some simple macros
> or SQL functions that do the encoding/decoding for external access. Or
> maybe a simple GRASS SQL table import/export function.
> 
> I think it is necessary to have all the possibilities available for
> table names.

Agreed. As things stand, "foo.bar" is a valid map name; if e.g. 
"v.extract ... output=foo.bar" fails, that is a bug in v.extract.

Simply changing the definition of a valid map name to match SQL syntax
is overkill (and seriously incompatible with previous versions). And
having different definitions of a valid map name depending upon
whether the module uses SQL just isn't acceptable.

A corollary of the above is that there has to exist some mechanism for
mapping map names to table names, and that mechanism can't be the
identity function.

BTW, any mechanism which results in collisions (e.g. converting all
non-alphanumeric characters to an underscore) isn't really acceptable
either[1].

[1] Having said that, I doubt that GRASS handles case correctly. If
map names are meant to be case-sensitive, using the map name as a
filename won't work on Windows. If they are meant to be
case-insensitive, this fact is bound to have been overlooked
somewhere.

-- 
Glynn Clements <glynn.clements at virgin.net>