On Thu, 07 Sep 2006 12:40:46 +0000
Brad Douglas wrote:
On Thu, 2006-09-07 at 13:35 +0200, Markus Neteler wrote:
> On Thu, Sep 07, 2006 at 11:12:18AM +0000, Brad Douglas wrote:
> > GRASS 6.3.cvs (hamilton2):/usr/src/grass6 > r.to.vect in=elizabeth.los
> > out=elizabeth.los feature=area
> > Illegal vector map name <elizabeth.los>. Character <.> not allowed.
> > ERROR: Map name is not SQL compliant.
> >
> > How do file names conflict with SQL92? I thought SQL92 only applied to
> > file contents. Is this also being used as a workaround for DBF
> > limitations? What I'm getting at is: Why is '.' not allowed? Doing a
> > quick archive search failed to illuminate any light bulbs in the
> > immediate vicinity.
>
> Hi Brad,
>
> AFAIK '.' is reserved for joins. '_' will work.
>
> See
> http://grass.itc.it/grass63/manuals/html63_user/sql.html
> -> NOTES
>
> It would be nice to have the naiming constraints relaxed but
> I am not sure if that's really possible.
'_' is also reserved for matching, so that can't be it.
Maybe a better question is: Why doesn't GRASS distinguish between tables
and files (database)? I would much prefer to have GRASS automatically
substitute '_' for '.' in the table name so I can keep consistent naming
conventions across rasters and vectors. It's a usability issue and
somewhat annoying. 
Well... To my knowledge standard SQL requires a letter as the first
character of a table name, and after that letters, numbers, or
underscores are permitted without quotation. If you want to break those
rules double quotes are required. So the error message is correct.
Using a period in a table name without double quoting is a violation of
SQL naming rules. Normally a period is used to related columns to
tables, aliases etc.
For example
select a.x, b.y
from schema_one.table_x a, schema_two.table_y b
where a.q = b.q
Thus it is impossible for SQL to know how to parse this without quotes.
I guess the real question is: How big of a job would this be? Radim?
If it isn't an overwhelming job, I'd like to propose it for 7.x.
Since we want to improve database support it seems reasonable to
provide subtle education for GRASS users about SQL sticking with SQL
naming restrictions. Therefore, it would be more logical to require
rasters to fit the same naming restrictions as vectors for the 7.x
line. There will be many users who will hate this idea as they are
used to using periods in their raster file names, but this would be
consistent.
That said, you are correct that we could implement quoting
of table names to allow rule breaking naming, but considering the
difficulties with quotes and bash, this is just a place we don't want
to go, AFAIC.
So for 7.x we should do one of two things. One, do nothing, as
relaxing the naming rules for vectors wouldn't be difficult, but it
would be unwise and would introduce all new levels frustration for
users not familiar with SQL. Two, enforce SQL and thus vector naming
restrictions for rasters for the sake of consistency.
T
--
Trevor Wiens
twiens@interbaun.com
The significant problems that we face cannot be solved at the same
level of thinking we were at when we created them.
(Albert Einstein)
