Re: BUG #14650: pg_dump -c fails when 'public' schema doesn't exist

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

In response to

Responses

Browse pgsql-bugs by date

  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