[Tagging] Is tagging of fuel: assumed to be exhaustive?

[Marc_marc]

Le 20.04.23 à 03:28, Matija Nalis a écrit :
> On Thu, 20 Apr 2023 00:47:21 +0200, Marc_marc <marc_marc at mailo.com> wrote:
>> Le 19.04.23 à 14:19, Matija Nalis a écrit :
>>> I think that my point remains that:
>>> - one method is clear and unambiguous ("fuel:lpg=no")
>>> - one method is not clear / is ambiguous ("fuel=octane_98;diesel").
>>>
>>> So the first one should be preferred. Does that make sense?
>>
>> - one is a nightmare for datause
>> - one isn't a nightmare for datause
>> So the 2nd one should be preferred. Does that make sense?
> 
> Hmm, no, not at all (if ordering of your sentences is same as mine at the top quote)?
> 
> I'll assume that by "datause" you mean something like computer storing
> data in some kind of database for purpose of retrieving

yes

> - in "fuel:lpg=no" case it is VERY efficient and fast (using const lookup
>    on composite index [key,value]) to look for e.g.
> 
>    SELECT * from t where key = "fuel:lpg" and value = "yes";

only if you are able to make an index on it
make a index on fuel=* is easy.
but creating an index on an unknown number of fuel:* keys is problematic
besides, this information will end up in the hstore for the same reason

for the preset, it's the same problem:
listing all cuisine=* values is possible (iD does it very well)
propose a preset that dynamically displays a yes/no field for all 
fuel:*, I've never seen this before, you're limited to hardcoding some

it is a confusion between key and value.