@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 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/c2160935...@github.com>
_______________________________________________
Kamailio (SER) - Development Mailing List
To unsubscribe send an email to sr-dev-le...@lists.kamailio.org
