Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you are subscribed to this thread.
@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/e047f35ad5e1d7b4984a9cce72ffb782fdae3bda/src/modules/htable/ht_db.c#L187).
I'll post back when I have more time to review this one in depth.
—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you are subscribed to this thread.