[GRASS-dev] Re: [bug #2829] (grass) v.to.db: the 'option' is parsed wrong if multiple 'option's are given in particular order

[Markus Neteler]

On Thu, Sep 21, 2006 at 05:10:54PM +0200, Maciek Sieczka via RT wrote:
> Markus,
> 
> As you have just fixed one parser error in the v.to.db, do you mind if I
> trigger your attention to another long-standing one?
> 
> If all the valid 'options', or specific combinations of them, are listed in a
> row, v.to.db accepts it *if they come in the same order as the are listed in
> the Description*.
> 
> spearfish60
> 
> For example - this works while it should not:
> 
> $ v.to.db -p map=landuse
> option=cat,area,compact,perimeter,length,count,coor,start,end,sides,query
> type=centroid col=col1
> 
> 8 categories read from map
> 0 records selected from table
> 0 categories read from map exist in selection from table
> 0 categories read from map don't exist in selection from table
> 0 records updated/inserted
> 0 update/insert errors
> 
> I can remove an option from the end of the comma-separated list and from the
> beginnig, and this will still work:
> 
> $ v.to.db -p map=landuse
> option=area,compact,perimeter,length,count,coor,start,end,sides type=centroid
> col=col1
> 
> And this too:
> 
> v.to.db -p map=landuse option=perimeter,length,count,coor type=centroid col=col1
> 
> But if I take out one somewhere in the middle *so that the order they are
> listed in Description IS NOT PRESERVED*, v.to.db returns an error like it should:
> 
> $ v.to.db -p map=landuse option=perimeter,length,coor type=centroid col=col1
> 
> Error: value <perimeter,length,coor> out of range for parameter <option>
>        Legal range:
> cat,area,compact,perimeter,length,count,coor,start,end,sides,query

I thought that it should *never* work since
vector/v.to.db/parse.c
    parms.option->multiple     = NO;

A bug in the parser?

Markus