On 2015-01-09 21:42, Tom Lane wrote:
> jeff.casavant@gmail.com writes:
>> Code to reproduce:
>
>> create function b() returns int as $$ select 1 $$ language sql;
>> create function a() returns int as $$ select b() $$ language sql;
>> create schema qwr;
>> create materialized view qwr.c as select a();
>
> 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.
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.
.marko