How about the slightly simplified
proc_doc db_nextval { sequence } {
Returns the next value for a sequence.
This can utilize a pool of sequence values to save hits to the database.
} {
# the following query will return a nextval if the sequnce
# is of relkind = 'S' (a sequnce). if it is not of relkind = 'S'
# we will try querying it as a view
if { [db_0or1row nextval_sequence "select nextval('${sequence}') as nextval
where (select relkind
from pg_class
where relname = '${sequence}') = 'S'"] } {
return $nextval
} else {
ns_log notice "db_nextval: sequence($sequence) is not a real sequence. perhaps it uses the view hack."
db_0or1row nextval_view "select ${sequence}.nextval as nextval"
return $nextval
}
}
I'd leave out the log or change it to the debug level though, we create a lot of objects and that's done using the view hack currently. This would be the first one to get rid of if someone wants to tackle this issue.
Also the comment about pools of sequences can go away. The object sequence is pooled at the SQL level and in the very beginning of the porting effort I got rid of pooling at the Tcl level.
