As noticed in Bug 163, in some cases, Slony functions need to have search_path set to indicate the @NAMESPACE@ of the cluster. If we were to define *all* functions in this fashion, we could safely omit a lot of references to @NAMESPACE@ inside these functions.
Or is the bug that some functions use search_path where they all should be called with @NAMESPACE@. Consider someone who wants to have 2 different slony clusters on the same database. If we always use @NAMESPACE@ and qualify table+function names this should not be a problem. If we start depending on search_path then we might start getting situations where the wrong sl_table gets used.
(In reply to comment #1) > Or is the bug that some functions use search_path where they all should be > called with @NAMESPACE@. What do you mean by "called with @NAMESPACE@"? @NAMESPACE@ is only evaluated at installation time. It is not involved at the time functions are called. > Consider someone who wants to have 2 different slony clusters on the same > database. If we always use @NAMESPACE@ and qualify table+function names this > should not be a problem. If we start depending on search_path then we might > start getting situations where the wrong sl_table gets used. If we have Slony functions set search_path at the time that the functions are defined, then there is no problem with having two slony clusters on the same database. - When functions relating to cluster "_a" are called, search path is set to "_a", and they get the right objects. - When functions relating to cluster "_b" are called, search path is set to "_b", again, providing the right objects. The very same piece of configuration, @NAMESPACE@, is being stored in one of two places: a) In each reference to tables, sequences, views, functions, so if we miss one, things will break. b) In the function's search_path setting. We get rid of a bunch of references to @NAMESPACE@ by putting it into the function definition.
> If we have Slony functions set search_path at the time that the functions are > defined, then there is no problem with having two slony clusters on the same > database. > > - When functions relating to cluster "_a" are called, search path is set to > "_a", and they get the right objects. > > - When functions relating to cluster "_b" are called, search path is set to > "_b", again, providing the right objects. > > The very same piece of configuration, @NAMESPACE@, is being stored in one of > two places: > > a) In each reference to tables, sequences, views, functions, so if we miss > one, things will break. > > b) In the function's search_path setting. > > We get rid of a bunch of references to @NAMESPACE@ by putting it into the > function definition. I misunderstood your comment. I thought you were taking about setting the search_path IN the function not as a parameter to CREATE FUNCTION. This makes more sense.