On 24 June 2013 10:21, Kohei KaiGai wrote:
Hi Simon,
I checked this patch. One thing I could comment on is, do you think it is
a good
idea to have oid of exception function list on
contain_volatile_functions_walker()?
The walker function is static thus here is no impact for other caller, and
its
"context" argument is unused.
My proposition is to enhance 2nd argument of
contain_volatile_functions_walker()
to deliver list of exceptional functions, then
contain_volatile_functions_not_nextval()
calls contain_volatile_functions_walker() with
list_make1_oid(F_NEXTVAL_OID) to
handle nextval() as exception.
Otherwise, all we need to do is put NIL as 2nd argument.
It kills code duplication and reduces future maintenance burden.
How about your opinion?
Hi Simon,
I checked this patch. One thing I could comment on is, do you think it is
a good
idea to have oid of exception function list on
contain_volatile_functions_walker()?
The walker function is static thus here is no impact for other caller, and
its
"context" argument is unused.
My proposition is to enhance 2nd argument of
contain_volatile_functions_walker()
to deliver list of exceptional functions, then
contain_volatile_functions_not_nextval()
calls contain_volatile_functions_walker() with
list_make1_oid(F_NEXTVAL_OID) to
handle nextval() as exception.
Otherwise, all we need to do is put NIL as 2nd argument.
It kills code duplication and reduces future maintenance burden.
How about your opinion?
Ultimately, I see this as a choice between a special purpose piece of code
(as originally supplied) and a much more generic facility for labelling
functions as to whether they contain SQL or not, per the SQL standard as
Jaime suggests. There's not much mileage in something in between.
So I'm mid way through updating the patch to implement the generic facility.
--
Simon Riggs http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services
