Re: Behavior of PL/pgSQL function following drop and re-create of a table that it uses - Mailing list pgsql-general

From David G. Johnston
Subject Re: Behavior of PL/pgSQL function following drop and re-create of a table that it uses
Date
Msg-id CAKFQuwYOqKig-KDzn+0F4cJ9knK=_zMt1GNk0OK5hWLfKTS-dw@mail.gmail.com
Whole thread Raw
In response to Re: Behavior of PL/pgSQL function following drop and re-create of a table that it uses  (Bryn Llewellyn <bryn@yugabyte.com>)
List pgsql-general
On Tue, Mar 7, 2023 at 10:19 PM Bryn Llewellyn <bryn@yugabyte.com> wrote:
Why not err on the side of caution and (I trust) guaranteed currency of each session's in-memory representation of a PL/pgSQL program with the environment in which it executes?

After all, you add a column in order to use it. And this means that at the very least client-side code must be changed to do this. And this means quiescing use of the application and then re-starting it with new behavior. Is re-starting the connection pool before opening up the new app for use so expensive that it's worth trying to reason when it might be safe to avoid this re-start?

True.  I was a bit hasty in forming an opinion on an operational aspect like that.  That just isn't something I typically think about.

David J.

pgsql-general by date:

Previous
From: Bryn Llewellyn
Date:
Subject: Re: Behavior of PL/pgSQL function following drop and re-create of a table that it uses
Next
From: Siddharth Jain
Date:
Subject: Re: could not bind IPv4 address "127.0.0.1": Address already in use