I see that sometimes it's possible to post a $filter OData request with numeric literal values suffixed with one letter, like can be tested here "round(Freight) eq 32l". It also works identically by removing the suffix or using suffixes m, M, L. If using d or f there's a type mismatch error (floating point literal used with an Edm.Decimal property). If using a, b (among others) it indicates a syntax error.
Sometimes, it seems that this suffix is mandatory, and sometimes not.
I have searched in the OData standards a little bit (my findings are described below). I came to the conclusion that in OData 2.0 these suffixes were mandatory, but since OData 3.0 these suffixes are invalid, and that if some OData 3.0 or 4.0 server implementations accept them, it's against the standards.
Could you confirm that, and could you share some official OData explanations to explain this big change between OData 2.0 and 3.0?
My findings:
(1) OData 2.0 > URI Conventions > 4.5. Filter System Query Option ($filter) (althouth the text "32d" refers to link with "32", but setting manually "32d" in the URL also works):
(2) OData 2.0 > Overview > 6. Primitive Data Types:
(3) OData 3.0 > URI Conventions > 4.5. Filter System Query Option ($filter) > Math Functions, there's no more mention of "32d":
(4) OData 4.01 > Part 1: Protocol > 11.2.6.1.2 Built-in Query Functions > Arithmetic Functions, there's no more mention of "32d":
(5) OData 4.01 > Part 2: URL Conventions > 5.1.1.9 Arithmetic Functions:
(6) OData 4.01 > ABNF > numeric literal values
