[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