Re: Stored procedure code no longer stored in v14 and v15, changed behaviour - Mailing list pgsql-general

From Pasi Oja-Nisula
Subject Re: Stored procedure code no longer stored in v14 and v15, changed behaviour
Date
Msg-id CAJvus-O6qvF_3jNHZdfX5f-5s3FLSHhUHVyPYtgCzftYH+CYXg@mail.gmail.com
Whole thread Raw
In response to Re: Stored procedure code no longer stored in v14 and v15, changed behaviour  (raf <raf@raf.org>)
Responses Re: Stored procedure code no longer stored in v14 and v15, changed behaviour  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-general
On Fri, 2 Dec 2022 at 15:47, raf <raf@raf.org> wrote:
> If you're concerned about tampering by
> customers/users/developers, you can either set
> permissions to prevent it in some cases, and when you
> can't prevent it, make it tamper-evident by logging
> actions to somewhere remote and monitoring for what
> concerns you. That should satisfy auditors.

True. But isn't this extra work compared to previous situation?
If you can compare procedure text directly and say to your developers
"you scoundrel did a change outside version control, no dessert for you".

I would be perfectly satisfied, if the sql that produced the procedure
would be stored "as is" read-only copy when it was compiled. If an object
rename makes it invalid, tweak a bit telling so, but don't change the text
until next alter procedure is run.

Pasi



pgsql-general by date:

Previous
From: Jeremy Smith
Date:
Subject: Re: Stored procedure code no longer stored in v14 and v15, changed behaviour
Next
From: "Peter J. Holzer"
Date:
Subject: Re: Stored procedure code no longer stored in v14 and v15, changed behaviour