News for hackers. Stuff that matters.
Re:Code in Database vs. Code in Application by anonymous23801 on Monday July 11, 2022 @04:17AM (#32053556)
You could easily create a new revision of the function you want to change, and have the first box to use the new revision while the rest keep using the old one.

In postgres that would be trivial with revision schemas and a clever usage of the SEARCH_PATH.

Re:Code in Database vs. Code in Application by swaranga on Thursday July 14, 2022 @11:05PM (#32104183)
Sure, it works for a narrow use-case like a pure function that just queries and returns data. What about stored procedures/triggers that mutate data on insert/delete etc?

With one-box, you can assign a specific set of customers/canaries to be served by the new 1-box and validate your results. If there is a problem you rollback and only your canary data was affected. It is just not very simple IMO.

Re:Code in Database vs. Code in Application by Smeevy on Monday July 11, 2022 @04:45AM (#32053700)
That is a neat idea. I was sort of thinking of that, but was concerned about invalid and unused database objects.

You'd avoid name collisions pretty handily, though. I'm guessing that you would just need some policy to drop all of the old versions after some period.

You'd also just need to bundle grant exec statements with the procedure DDL.

That would work well with Oracle and DB2 as well. I'm not totally sure about SQL Server, though.