Re: BUG #13458: postgres_fdw with usermapping dumped with pg_dump --no-owners results in dump file with implicit own

gregburek@heroku.com writes:
> Reproduction schema:

> CREATE SERVER redshift_dw FOREIGN DATA WRAPPER postgres_fdw OPTIONS (
>     dbname 'reporting',
>     host 'example.com',
>     port '5439',
>     sslmode 'require'
> );
> ALTER SERVER redshift_dw OWNER TO u5cuus46hhtdfs;
> CREATE USER MAPPING FOR u5cuus46hhtdfs SERVER redshift_dw OPTIONS (
>     password '',
>     "user" 'user'
> );

> A pg_dump --no-acl --no-owner will reference the user:

> --
> -- TOC entry 4313 (class 0 OID 0)
> -- Dependencies: 2216
> -- Name: USER MAPPING u5cuus46hhtdfs SERVER redshift_dw; Type: USER MAPPING;
> Schema: -; Owner: -
> --
> CREATE USER MAPPING FOR u5cuus46hhtdfs SERVER redshift_dw OPTIONS (

> And a pg_restore --no-acl --no-owner will fail on this line as pg_restore is
> using a different user:

> pg_restore: [archiver (db)] Error from TOC entry 4491; 0 0 USER MAPPING USER
> MAPPING u5cuus46hhtdfs SERVER redshift_dw u5cuus46hhtdfs
> pg_restore: [archiver (db)] could not execute query: ERROR:  role
> "u5cuus46hhtdfs" does not exist
> Command was: CREATE USER MAPPING FOR u5cuus46hhtdfs SERVER redshift_dw
> OPTIONS (

This does not seem like a bug to me.  The only thing we could really do
to avoid the error is to decree that pg_restore should treat USER MAPPING
objects as being suppressed altogether by --no-acl or --no-owner; and
I'm doubtful that that would be an improvement.

            regards, tom lane