Re: BUG #6706: pg_upgrade fails when plpgsql dropped/re-created - Mailing list pgsql-bugs

From Bruce Momjian
Subject Re: BUG #6706: pg_upgrade fails when plpgsql dropped/re-created
Date
Msg-id 20120704213703.GH5578@momjian.us
Whole thread Raw
In response to Re: BUG #6706: pg_upgrade fails when plpgsql dropped/re-created  (Bruce Momjian <bruce@momjian.us>)
Responses Re: BUG #6706: pg_upgrade fails when plpgsql dropped/re-created  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-bugs
On Mon, Jul 02, 2012 at 01:28:36PM -0400, Bruce Momjian wrote:
> This is the trimmed-down code block:
>
>     if (!binary_upgrade)
>     {
>         appendPQExpBuffer(q, "CREATE EXTENSION IF NOT EXISTS %s WITH SCHEMA %s;\n",
>                           qextname, fmtId(extinfo->namespace));
>     }
>     else
>     {
> -->     appendPQExpBuffer(q, "DROP EXTENSION IF EXISTS %s;\n", qextname);
>         appendPQExpBuffer(q,
>                           "SELECT binary_upgrade.create_empty_extension(");
>
> The idea is that the IF NOT EXISTS and IF EXISTS are symmetric, which is
> my goal.
>
> > address the points I made about reproducing the previous state in cases
> > where the admin removed the language or changed its permissions.
>
> Well, it still does the create extension in binary mode like before ---
> not sure what the problem is.

Applied and back-patched to 9.2.

--
  Bruce Momjian  <bruce@momjian.us>        http://momjian.us
  EnterpriseDB                             http://enterprisedb.com

  + It's impossible for everything to be true. +

pgsql-bugs by date:

Previous
From: Josh Kupershmidt
Date:
Subject: Re: BUG #6715: 9.2b2 psql \ir does not understand leading ../
Next
From: Tom Lane
Date:
Subject: Re: BUG #6706: pg_upgrade fails when plpgsql dropped/re-created