Re: pg_dumpall problem when roles have default schemas

Tom Lane wrote:
> btober(at)ct(dot)metrocast(dot)net writes:
>> Thus, when piping the output (from legacy host 192.168.2.2) to
>> populate the newly initialized cluster, by way of running (on the new
>> host 192.168.2.3)
>> pg_dumpall -h 192.168.2.2|psql
>> an error occurs in that first section when the script attempts to
>> set a role-specific search path ... because the schema named in the
>> search path hasn't been created yet.
>
> Could we see a complete example?
>
> Recent versions of the backend are not supposed to throw hard errors in
> this situation, because of exactly that hazard. For instance:
>
> regression=# create role joe;
> CREATE ROLE
> regression=# alter role joe set search_path to foo, bar;
> NOTICE: schema "foo" does not exist
> NOTICE: schema "bar" does not exist
> ALTER ROLE
> regression=#
>
> which AFAICS is exactly what will happen while restoring a pg_dumpall
> dump.

Ah, I understand. I think.

What I saw was not literally and "error", but rather a "notice": The
"alter role ... set search_path" statement doesn't actually fail.

The real problem is my preconceived notion. I was thinking in terms of,
say, a database insert to a table with a foreign key, i.e., that since
the schema to be set doesn't exist, the the statement should actually fail.

The implication of your illustration above is that the "alter role ...
set search_path" statement completes successfully even though it is
setting an invalid search path (invalid because the schema referenced in
the search path to be set does not exist at the time the statement is
executed).

So this behavior, which seems a little counter intuitive, actually makes
for a robust end result.