From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Keith Hickey <kwhickey(at)gmail(dot)com> |
Cc: | pgsql-bugs(at)lists(dot)postgresql(dot)org |
Subject: | Re: BUG #15282: Materialized view with transitive TYPE dependency fails refresh using pg_restore and psql |
Date: | 2018-07-18 16:07:47 |
Message-ID: | 14401.1531930067@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-bugs |
Keith Hickey <kwhickey(at)gmail(dot)com> writes:
> But then I saw this config setting embedded at the top of the plain sql
> dump file:
> SELECT pg_catalog.set_config('search_path', '', false);
Right, that's what implements the change in behavior.
> So it looks like pg_dump somehow embeds clearing the search_path into its
> dumps. There doesn't seem to be a way in pg_dump to tell it to do this or
> not to do this.
I argued at the time that there should be an option to let it run with
some other search path, with the security implications being on the user's
head to worry about. I lost that argument, but I still think that we're
going to have to provide such a feature. Lately we've been seeing about
one complaint a week about this, as uptake of the locked-down versions
increases.
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | firstname lastname | 2018-07-18 21:47:40 | Re: BUG #15263: pg_dump / psql failure. When loading, psql does not see function-based constraints or indices |
Previous Message | Keith Hickey | 2018-07-18 15:35:38 | Re: BUG #15282: Materialized view with transitive TYPE dependency fails refresh using pg_restore and psql |