@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/e047f35ad5e1d7b4984a9cce72ffb782f…).
I'll post back when I have more time to review this one in depth.
--
Reply to this email directly or view it on GitHub:
https://github.com/kamailio/kamailio/pull/3828#issuecomment-2160935296
You are receiving this because you are subscribed to this thread.
Message ID: <kamailio/kamailio/pull/3828/c2160935296(a)github.com>