@miconda just wanted to post back real quick on this one, I think this might take a little while to review...
``` ~/projects/kamailio|[git:sr_3.1_freeze:master !]$ grep -RE -m 1 -l 'db_val2pv_spec|db1_res_t' src/modules/ | cut -d '/' -f 3 | sort -u alias_db auth_db avpops carrierroute cplc db_berkeley db_cassandra db_cluster db_mongodb db_mysql db_oracle db_perlvdb db_postgres db_redis db_sqlite db_text db_unixodbc dialog dialplan dispatcher domain domainpolicy drouting group htable imc ims_charging ims_dialog ims_icscf ims_usrloc_pcscf ims_usrloc_scscf lcr matrix mohqueue mqueue msilo mtree pdt permissions pipelimit presence presence_xml pua p_usrloc rls rtpengine rtpproxy sca secfilter speeddial sqlops topos uac uri_db userblocklist usrloc utils xcap_client xcap_server xhttp_pi ```
I have not had time to deep dive into this yet but there is probably a better way to filter down the list of modules converting those `db1_res_t` variables to pseudo variables. As far as I can tell though, even the references that are not eventually converted to PVs should be reviewed in case the logic was written without that assumption in mind. For example, I can already see in htable another case where a db_result_t in `ht_db_load_table()` is assumed to only to be an integer type and is used for indexing in the hash table (follow this variable down https://github.com/kamailio/kamailio/blob/e047f35ad5e1d7b4984a9cce72ffb782fd...).
I'll post back when I have more time to review this one in depth.