Re: Instead of DROP function use UPDATE pg_proc in an upgrade extension script

From: Robert Haas <robertmhaas(at)gmail(dot)com>
To: Vicky Vergara <vicky_vergara(at)hotmail(dot)com>
Cc: Andrew Gierth <andrew(at)tao11(dot)riddles(dot)org(dot)uk>, "pgsql-hackers(at)postgresql(dot)org" <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Instead of DROP function use UPDATE pg_proc in an upgrade extension script
Date: 2017-04-04 16:43:23
Message-ID: CA+Tgmob4LsSjeCM8h18RB4EaSn2jZucfooauZrMd4fBpp+XeUA@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Tue, Apr 4, 2017 at 9:07 AM, Vicky Vergara <vicky_vergara(at)hotmail(dot)com> wrote:
> you answered so fast that I know I am stepping into dangerous grounds.
>
> But I would like to know more about your experience.
>
> Any links that you can give me to read about the code and/or issues
> regarding the ip4r experience?

I can't comment on that, but in general I don't think there's an issue
if (1) your UPDATE statement contains no bugs and (2) the DROP
statement would have succeeded without CASCADE. The problem is when
there's stuff depending on the existing function definition - such as
views. Even then it may work if the dependencies are such that the
new definition is compatible enough for purposes of the dependent
objects, but if not then you've got trouble.

To put this another way, if it were safe for CREATE OR REPLACE to
succeed here, we would have made it succeed.

--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Robert Haas 2017-04-04 16:49:43 Re: ANALYZE command progress checker
Previous Message David Steele 2017-04-04 16:23:25 Re: PATCH: Make pg_stop_backup() archive wait optional