anton7r

By caching the index of a field we make querying values by field name faster, but however where we only query one field the optimizations wont help performance as seen...

Performance is no longer a concern ``` goos: windows goarch: amd64 pkg: github.com/georgysavva/scany/queryparser/utils cpu: AMD Ryzen 7 2700X Eight-Core Processor BenchmarkGetNamedField-16 6281607 187.7 ns/op 32 B/op 3 allocs/op BenchmarkIndexMap-16 3786922...

sure, when i wrote the lexer 6 months ago i just wanted to learn how they work. It is not only error prone, but it also doesn't support every data...

having looked at the way sqlx has done it i noticed that it is not done by the most optimal way as it converts the entire struct into a `map[string]interface{}`...

allocating that much memory for the strings still sounds kinda bad in my opinion maybe i could use the "ordinal" value of the field as the key which would reduce...

@georgysavva should the NamedGet and NamedSelect actually be GetNamed and SelectNamed since it would probably be easier when autocompleting in IDEs?

If we do not give the sqlscan interface a default value for the compile delimeter. would we then need to get rid of the package level api that it has?

i dont think using the getColumnToFieldIndexMap() with the same casing as the database table names etc... because if you have the named params camel cased it increases readability in my...

I undestand your point but in this case simple may not be the best solution if we want scany to be a high productivity tool. We also do not want...

also it seems like `getColumnToFieldIndexMap()` may need some caching as it seems to do the expensive reflect field name computations