Marko Tiikkaja <marko@joh.to> writes:
> On 2015-01-09 21:42, Tom Lane wrote:
>> This is not a pg_dump bug, this is a broken definition of function a().
>> That function will fail in any context where the caller changes
>> search_path, not only pg_dump. You can perhaps get away without that
>> in a single-schema database, but not with multiple schemas.
> AFAIK there isn't a way to write inlineable SQL functions in relocatable
> extensions in that way, since you don't know which schema they end up
> installed in. The original test case comes from PostGIS.
You can do it for relocatable-at-install-time extensions, as suggested in
the manual:
CREATE FUNCTION ... SET search_path = @extschema@ ...
> But I think the bigger problem is that naively thinking it shouldn't be
> this easy to create unrestorable databases. But perhaps I'm being
> overly naive.
Well, if you know how to inform pg_dump what random assumptions about
search_path exist in the functions invoked by a matview (or expression
index, or some other cases), let me know.
regards, tom lane
