I have been doing some more debugging in db_exec proc and found some more clues. First of all the driverkey that is picked was the wrong one see below: driverkey=oracle when the driver key should have been postgres in the case. This makes me think that the db_driverkey proc is picking the wrong driver in some cases
ad_proc -public db_exec { {-subst all} type db statement_name pre_sql {ulevel 2} args } {
A helper procedure to execute a SQL statement, potentially binding
depending on the value of the $bind variable in the calling environment
(if set).
@param subst Perform Tcl substitution in xql-files. Possible values: all, none, vars, commands
} {
set start_time [expr {[clock clicks -microseconds]/1000.0}]
set driverkey [db_driverkey -handle_p 1 $db]
if {$driverkey == "oracle"} {
ns_log notice "== driverkey=$driverkey type=$type statement_name=$statement_name args=$args"
}
I am not sure if this has anything to do with or or not but we also are using xql files for most of the postgres queries in this particular case
[29/Sep/2021:06:45:26][1.7f69fbfff700][-sched:0:3080:137-] Notice: nsdbpg(pool2): opened connection to east-intra-pgdb:5432:east_intra.
62689 [29/Sep/2021:06:45:26][1.7f69fbfff700][-sched:0:3080:137-] Notice: == driverkey=oracle type=0or1row statement_name=dbqd.usurf-swbill.tcl.cron-procs.swb::post_service_center_charges.getEmpName args=
62690 [29/Sep/2021:06:45:26][1.7f69fbfff700][-sched:0:3080:137-] Notice: ### db_with_handle returned error handle: "'0or1row' is not of type Oracle8" for statement
