From: | Michael Paquier <michael(dot)paquier(at)gmail(dot)com> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | tureba(at)gmail(dot)com, Stephen Frost <sfrost(at)snowman(dot)net>, PostgreSQL mailing lists <pgsql-bugs(at)postgresql(dot)org> |
Subject: | Re: BUG #14650: pg_dump -c fails when 'public' schema doesn't exist |
Date: | 2017-05-13 22:54:08 |
Message-ID: | CAB7nPqTYuKYS4R=GBqL7tCpN67DPDTNGuf6JcH-RH1_vpEEoLQ@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-bugs |
On Sat, May 13, 2017 at 3:22 AM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> tureba(at)gmail(dot)com writes:
>> It seems that pg_dump -c fails when the database doesn't have a 'public'
>> schema. When using a clean database, then dropping (or renaming) the
>> 'public' schema, a subsequent pg_dump -c tells me:
>
>> $ pg_dump -c test
>> pg_dump: [archiver (db)] query failed: ERROR: schema "public" does not exist
>> LINE 1: ...::regclass AND pip.objsubid = 0 AND pip.objoid <> 'public'::...
>> ^
>
>> This seems to have started in commit 330b84d8c4
>
> Yeah, this is not cool. Stephen?
This is visibly an oversight of the recent commit 330b84d, which is
broken on its face because it does not check for the existence of this
schema. One simple fix would be to extend this query with a SELECT
CASE ... ELSE 0 FROM pg_namespace WHERE nspname = 'public' but that's
ugly.
--
Michael
From | Date | Subject | |
---|---|---|---|
Next Message | Andres Freund | 2017-05-13 23:16:11 | Re: BUG #14530: Logical Decoding Slowness |
Previous Message | Michael Paquier | 2017-05-13 22:47:04 | Re: Postgres 9.6.3 pg_dump issue |