[GRASS-dev] v.db.update: any reason to keep both value and qcolumn parameter ?

Hamish hamish_b at yahoo.com
Wed Oct 1 02:05:19 EDT 2008


>>> 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).

this puts it at odds with the value= option description, both WRT quotes
and combinations:
 "Value to update the column with (varchar values have to be in single
  quotes, e.g. 'grass'), can be (combination of) other column(s)"


>>> So, we should either:
>>>
>>> - change the doc to reflect that value should only be a nominal
>>> value, or
Markus:
> > 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 quoting
> > 
> > No - 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.
Glynn: 
> 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=.

Replacing qcolumn= with expression= sounds good to me. It's more to the
point.

At which point value= becomes a little redundant, but it helps to avoid
a some minor 'quote' proofing when used from the shell.


Hamish



      



More information about the grass-dev mailing list