Stephen, as a pro-pg-lobbyist, I tend to like your suggestion, though I don't think it helps in this case.
The following function is the result of some chatting with DanW on this issue:
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
db_0or1row nextval_sequence "select nextval('${sequence}') as nextval
where (select relkind
from pg_class
where relname = '${sequence}') = 'S'"
if {[info exists nextval]} {
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
}
}
If the sequence is a true PG sequence, this modifed version of the function only uses one query instead of two. Might provide some speed improvement, so we are going to go with this one for now.
I am committing this change now, so that more pages will start to work on postgres (such as customizing portlets). This isn't set in stone, of course -- so continue to post comments/criticisms -- but we do need a temporary bandaid for now...
