Estratégia para fazer o Postgres suportar várias versões do código do cliente

Estou prestes a embarcar em uma revisão geral do nosso código para enviar para o Postgres e quero solicitar alguns comentários antes de continuar.

A configuração aqui é que temos muitos softwares implantados com um banco de dados não Postgres, onde periodicamente enviamos linhas para um banco de dados Postgres central. (RDS 11.4) As chances de atualizarmos todas as cópias implantadas do código simultaneamente são zero . Então, sempre teremos várias versões ativas no campo... às vezes muitas versões diferentes. Tudo bem por si só, mas torna incontrolável inserir declarações ingênuas INSERTno código do cliente. O que eu fiz. Ele só nos mordeu um pouco, mas pode acabar se tornando extremamente doloroso. Qualquer e todas as seguintes alterações de DDL em nosso Postgres central podem interromper pushes de software implantado em uma versão antiga:

• Remover um campo
• Renomear um campo
• Digite novamente um campo
• Adicionar um NOT NULL DEFAULT NULLcampo

Afirmando o óbvio, tenho que mover referências fixas/codificadas do código do cliente para outra coisa . A maioria das pessoas provavelmente tem algum tipo de pilha com um ORM, etc. entre seu aplicativo coletor/campo e o Postgres. Nós não. Então, com muita ajuda das pessoas aqui no SO, eu construí a seguinte solução, usando "hsys" como uma tabela de exemplo.

1. Para cada versão de tabela, crie um tipo personalizado, como hsys_v1.

   CREATE TYPE api.hsys_v1 AS (
       id uuid,
       name_ citext,
       marked_for_deletion boolean);
   

2. Para cada tabela e versão, escreva uma função de manipulação INSERT que aceite uma matriz do tipo personalizado.

   CREATE OR REPLACE FUNCTION ascendco.insert_hsys_v1 (data_in api.hsys_v1[])
     RETURNS int
   AS $BODY$
   
   -- The CTE below is a roundabout way of returning an insertion count from a pure SQL function in Postgres.
   with inserted_rows as (
           INSERT INTO hsys (
               id,
               name_,
               marked_for_deletion)
   
           SELECT
               rows_in.id,
               rows_in.name_,
               rows_in.marked_for_deletion
   
           FROM unnest(data_in) as rows_in
   
           ON CONFLICT(id) DO UPDATE SET
               name_ = EXCLUDED.name_,
               marked_for_deletion = EXCLUDED.marked_for_deletion
   
           returning 1 as row_counter)
   
       select sum(row_counter)::integer from inserted_rows;
   
   $BODY$
   LANGUAGE sql;
   

   A ideia aqui é que quando eu mudar a tabela, eu possa criar um hsys_v2tipo e uma insert_hsys_v2 (hsys_v2[])função para corresponder. Em seguida, os clientes antigos podem continuar enviando no formato antigo, desde que eu reescreva insert_hsys_v1para mapear/converter/coagir as coisas para o novo formato de tabela.

Eu escrevi uma GUI para pegar minhas definições de tabela e colocar um gerador de código no topo algumas semanas atrás. E então eu parei. Percebo que estou me perguntando se estou perdendo algo que devo considerar e espero que alguém aponte uma falha nessa estratégia. Não estou com preguiça de entrar em contato com programadores locais... não há nenhum. (Estou na Austrália rural.)

Se não houver nada de errado com essa estratégia, farei a revisão. Como bônus, o trabalho até agora facilitou a adição de construtores de código para conversões e visualizações personalizadas. Não tenho certeza se eles serão úteis ou não, mas estou gerando-os ao mesmo tempo.