diretamente no servidor da empresa
porque era o banco local de um cliente que deu acesso

Se conectar direto em produção para fazer QUALQUER alteração é sempre um risco que você está assumindo.

Aqui vai uma boa prática para executar em scripts em produção:

Trabalhava em uma empresa que tinha um DBA dedicado, SOMENTE ELE tinha permissão de usar escrita do DB de produção (outras pessoas tinham como fallback caso ele não tivesse, mas tinham muito mais cuidado porque era papo de justa causa)

Todos os outros tinham acesso somente leitura.

Cada script que fosse executado em produção deveria ter a seguinte estrutura:

DO $$
DECLARE
    registros_alterados INTEGER;
BEGIN
    -- Executa o UPDATE
    UPDATE table_name 
    SET col = 'teste' 
    WHERE col IS NULL;
    
    -- Captura o número de registros alterados
    GET DIAGNOSTICS registros_alterados = ROW_COUNT;
    
    -- Verifica se foram alterados exatamente 5 registros
    IF registros_alterados != 5 THEN
        RAISE NOTICE 'Número de registros diferente de 5. Fazendo ROLLBACK.';
        ROLLBACK;
    ELSE
        RAISE NOTICE 'Exatamente 5 registros alterados. Fazendo COMMIT.';
        COMMIT;
    END IF;
    
EXCEPTION
    WHEN OTHERS THEN
        RAISE NOTICE 'Erro: %. Fazendo ROLLBACK.', SQLERRM;
        ROLLBACK;
END $$;

Isso obriga você a saber exatamente qual o impacto do script, pra saber o numero de registros alterados precisa pelo menos fazer um select para validar os dados.

Se tivesse algum script que não podesse ser validado dessa forma ou alguma alteração massiva o processo era bem diferente:

• Copiar o DB de produção para base de teste
• Executar o script na base de teste
• Fazer uma auditoria profunda sobre quais foram os impactos
• Executar o script em produção

Esse processo poderia demorar até uma semana, o DB era massivo, e o custo para fazer dessa forma era gigantesco, mas era seguro

Hoje como não tenho uma estrutura tão grande e robusta adoto uma prática parecida:

Todos os script só podem ser executados depois de passar por revisão por outra pessoa, ter testes em uma cópia parcial do banco, validar em um segundo ambiente. Eu sou o único que tenho permissão de escrita direto no banco, então posso garantir esse processo.

Mecher direto em produção é sempre um risco gigantesco, prefira uma estratégia de copy-on-edit precisa alterar uma configuração no servidor? clone ele completamente, altere, teste, mude os apontamentos para esse novo servidor, mantenha um tempo para garantir estabilidade e só depois remova o antigo (isso funciona muito em ambientes cloud, on-premisse é mais difícil ter hardware sobrando)