### Description
I came across the following while trying to serialize SQL data to xavp (`sql_xquery()`) and then serializing the result to htable using `xavp_params_implode()`. One of the data columns has a type of `BIGINT`. The resulting string had neither the key nor value.
I recognize that Kamailio does not currently have support for 64 bit integers and that adding support for it is probably not a trivial matter. My request here is really that if the value is going to be dropped it would be good if `pv` would omit a warning.
#### Reproduction
MySQL table:
```sql CREATE TABLE dids ( id INT NOT NULL AUTO_INCREMENT PRIMARY KEY, did varchar(11) NOT NULL, route_id BIGINT NOT NULL, failure_route_id INT NOT NULL, description VARCHAR(255) ); ```
With data like this: ```sql INSERT INTO dids ( did, route_id, failure_route_id, description ) VALUES ( '15555551000', 101, 1006, 'Alice' ); ```
And the following Kamailio code: ``` $var(query) = "SELECT * " + "FROM dids " + "WHERE did = " + $(rU{sql.val.str});
sql_xquery("db", "$var(query)", "did_data"); xavp_params_implode("did_data", "$sht(did=>$rU)"); xinfo("Serialized query result: [$sht(did=>$rU)]\n"); ``` The following log line results - the `route_id` is missing all together: ``` 1(7) INFO: <script>: Serialized query result: [id=1;did=15555551000;failure_route_id=1006;description=Alice;] ```
### Possible Solutions
It's worth noting that the value is usable out of the XAVP. `$xavp(did=>route_id)` is retrievable, and the problem seems to be only when running `xavp_params_implode()`. In a perfect world, the key and value would be retained and put into the serialized data, however I'm not sure of the complexity of this (what if the the value exceeds a 32 bit int?, etc). With that said, my only real request would be that if a value is dropped that a warning is omitted with a rough explanation of the reason ("omitting _keyName_ unknown_ data type", etc).
### Additional Information
* **Kamailio Version** - output of `kamailio -v`
``` 5.7.3 ```
* **Operating System**:
Alpine 3.18
I have just added support to serialize `long long` values (commit b7b3f94f94), which should cover the reported case.
There is a `debug` message when a field is skipped from serialization, it can be made `info` or `warning`, but then it might become too verbose, an xavp can hold internally more types than what config operations can deal with.
Some debug messages were made info when such cases happen, should help spotting them better. Closing.
Closed #3663 as completed.