voice: 480-965-6262; fax: 480-965-7671
www: http://www.public.asu.edu/~cmbarton
On Sep 30, 2008, at 8:48 AM, <grass-dev-request@lists.osgeo.org> <grass-dev-request@lists.osgeo.org > wrote:
Date: Tue, 30 Sep 2008 15:44:48 +0100
From: Glynn Clements <glynn@gclements.plus.com>
Subject: Re: [GRASS-dev] v.db.update: any reason to keep both value
and qcolumn parameter ?
To: "Markus Neteler" <neteler@osgeo.org>
Cc: grass-dev <grass-dev@lists.osgeo.org>
Message-ID: <18658.15200.914210.187542@cerise.gclements.plus.com>
Content-Type: text/plain; charset=us-asciiMarkus Neteler wrote:
However, in its current version (since rev 23578), value is now adapted
according to column type, which means that you cannot use column operations
on varchar columns (e.g. concatenation).So, we should either:
- change the doc to reflect that value should only be a nominal value, or
yes
- go back to the original, i.e. no qcolumn and no type checking for value,
so that it's up to the user to use correct quotingNo - I don't find it obvious at all that "value" could be a column name.
qcolumn also exists in other commands AFAIK, to that's consistent.Another option: add expression=, which is just used verbatim as the
RHS of the assignment (you can already use qcolumn= this way, but its
name and description makes that counter-intuitive). Optionally remove
value= and/or qcolumn=.
From a usability perspective, I think expression= is much better and more understandable than value= and qcolumn=. I've regularly been confused by these.
Michael
--
Glynn Clements <glynn@gclements.plus.com>