| From: | Steve Wampler <swampler(at)nso(dot)edu> |
|---|---|
| To: | "David G(dot) Johnston" <david(dot)g(dot)johnston(at)gmail(dot)com> |
| Cc: | Postgres-General <pgsql-general(at)postgresql(dot)org> |
| Subject: | Re: Odd messages on reloading DB table |
| Date: | 2019-02-11 19:29:57 |
| Message-ID: | 69add2d8-f3ba-3e06-ce13-008cd8696ce0@nso.edu |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-general |
On 2/7/19 3:24 PM, David G. Johnston wrote:
> On Thursday, February 7, 2019, Steve Wampler <swampler(at)nso(dot)edu <mailto:swampler(at)nso(dot)edu>> wrote:
>
> (1) the table already exist and the immediately doesn't exist?
> (2) report ERROR on UPDATE when there are no UPDATES in the input file
>
>
>
> Most likely the first attempt was schema qualified and so found the existing targets table while the second attempt was
> not schema qualified and targets is not in the search path.
>
> One guess I have is that triggers are involved here and those triggers need to be more resiliant in face of the recent
> search_path security update.
Thanks - but I thought the search_path update was a PG 10 change and so shouldn't reflect on 9.5.15 behavior. Did it
get back-ported?
In any event I'm surprised that pg_dump for 9.5.15 can produce a dump that can't be restored by either pg_restore
(when -Fc is used on both ends) or with psql (without -Fc used on pg_dump). I would have expected some message
from pg_dump if it ran into issues preventing this.
--
Steve Wampler -- swampler(at)nso(dot)edu
The gods that smiled on your birth are now laughing out loud.
| From | Date | Subject | |
|---|---|---|---|
| Next Message | David G. Johnston | 2019-02-11 20:03:29 | Re: Odd messages on reloading DB table |
| Previous Message | Adrian Klaver | 2019-02-11 16:53:35 | Re: Copy entire schema A to a different schema B |