Mentat

I think that this is not possible due to the nature of IDEA format. There is a possibility for different that defined values to occur for example within the Category field, data format must therefore allow storing arbitrary values, not only those in the specification. Additionally, some of the values like EventClass might seem to be picked from constant set of values, this is sadly only illusion. These sets are deployment specific and can change with addition of new data sources.

I consider a dynamic evaluation a feature for users - there are only searchable values in the search pulldowns, not all values (event not sensible ones). So unless I misunderstand, I don't think it's a good idea.

However, Mek, if we implement #4383, we will cease to support arbitrary values no matter what. That does not depend on having computed or static lists.

Jan Mach wrote:

I think that this is not possible due to the nature of IDEA format. There is a possibility for different that defined values to occur for example within the Category field, data format must therefore allow storing arbitrary values, not only those in the specification. Additionally, some of the values like EventClass might seem to be picked from constant set of values, this is sadly only illusion. These sets are deployment specific and can change with addition of new data sources.

This would mean that #4383 is essentially flawed and not a way to go.

Have you considered the remark in the last sentence? ENUM data types in PostgreSQL are extensible - if a new value is observed, it can be added. This could even work as a sanity check. For example, what other values for severity are there except for those well-known? Same for categories. In theory, any value is possible, in reality, new ones are not added often, we pick from a well-known set.

Inspector (or importer?) could then mark events using a non-standard value in any of the ENUM columns.

Only problem would be with those ENUMs where order is important (as is with categories - we would like to filter for all of the same first part in compound ones - i.e. Abusive.* - just like described in #4348) as reordering ENUM values is nontrivial, efficiently requiring table dump, retype and table restore. An example would be adding a "very low" severity into ("low", "medium", "high", "critical").

Do you see ENUMs viable at least for non-ordered sets of values? What about the checks? Is that a non-feature?

Pavel Kácha wrote:

I consider a dynamic evaluation a feature for users - there are only searchable values in the search pulldowns, not all values (event not sensible ones).

I see. Then there is the issue that a "no value" option is present even for NOT NULL columns - this would return no data. Similarly for the "any value" option - meaningless filtering condition for a NOT NULL column - all entries match.

So unless I misunderstand, I don't think it's a good idea.
However, Mek, if we implement #4383, we will cease to support arbitrary values no matter what. That does not depend on having computed or static lists.

I think we need to discuss this, you two obviously have different understanding of this issue.