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

[Michael Barton]

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 at lists.osgeo.org> <grass-dev-request at lists.osgeo.org 
 > wrote:

> Date: Tue, 30 Sep 2008 15:44:48 +0100
> From: Glynn Clements <glynn at gclements.plus.com>
> Subject: Re: [GRASS-dev] v.db.update: any reason to keep both value
> 	and	qcolumn parameter ?
> To: "Markus Neteler" <neteler at osgeo.org>
> Cc: grass-dev <grass-dev at lists.osgeo.org>
> Message-ID: <18658.15200.914210.187542 at cerise.gclements.plus.com>
> Content-Type: text/plain; charset=us-ascii
>
>
> Markus 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 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.
>
> 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 at gclements.plus.com>