Re: Stored procedure code no longer stored in v14 and v15, changed behaviour

On 12/1/22 09:24, Dominique Devienne wrote:
> On Thu, Dec 1, 2022 at 5:10 PM Laurenz Albe <laurenz(dot)albe(at)cybertec(dot)at> wrote:
>> On Thu, 2022-12-01 at 16:38 +0100, Dominique Devienne wrote:
>>> FWIW, we have a custom schema introspection and diff'ing ad-hoc framework,
>>
>> This is arguable, but my opinion is that this is not a robust way to
>> do development. You should use a schema versioning tool like Liquibase,
>> develop schema migration scripts and maintain the SQL code in a source
>> repository like other software.
>
> We don't maintain SQL. We maintain a *Logical* model, and generate the
> physical model from it.
> FKs, NKs, Enums, CHECK constraints, indexes, etc.. all that
> "implementation details"
> is programmatically generated, and always consistent, from a much
> higher-level and simpler model.
> And you also get auto-upgrade most of the time, greatly increasing
> development velocity too.
>
> I would argue that NOT doing it this way, is the non-robust way myself :)
> We've been refactoring a large data-model maintained manually like you advocate,
> and I can't tell you how many anomalies we've discovered and had to fix,
> using the more robust formalism of using a high-level logical model
> and (DDL) code gen.
>
> I guess is a DBA-versus-Developer point-of-view difference. --DD

What this points to is that there are multiple ways to handle this, many
external to the server itself. My take is that the system catalogs are
there for the proper operation of the server and that is their task,
first and foremost. If you can piggyback of that then great, but with
the knowledge that the information may change to meet the needs of the
server not external users.

--
Adrian Klaver
adrian(dot)klaver(at)aklaver(dot)com