Bug 184 - Set search_path for most/all Slony functions?
Summary: Set search_path for most/all Slony functions?
Status: NEW
Alias: None
Product: Slony-I
Classification: Unclassified
Component: core scripts (show other bugs)
Version: devel
Hardware: All All
: low enhancement
Assignee: Slony Bugs List
URL:
Depends on:
Blocks:
 
Reported: 2010-12-08 14:41 UTC by Christopher Browne
Modified: 2010-12-09 10:10 UTC (History)
1 user (show)

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Christopher Browne 2010-12-08 14:41:15 UTC
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.
Comment 1 Steve Singer 2010-12-09 04:50:16 UTC
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.
Comment 2 Christopher Browne 2010-12-09 08:21:21 UTC
(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.
Comment 3 Steve Singer 2010-12-09 10:10:03 UTC
> 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.