Aqui está o brief do podcast em formato Markdown:

---

## Resumo

Olá, devs OutSystems! Se você está migrando ou desenvolvendo no OutSystems Developer Cloud (ODC), prepare-se para uma mudança importante: o banco de dados padrão é o Aurora PostgreSQL, e não mais SQL Server ou Oracle como no OutSystems 11.

Isso significa que suas Advanced Queries SQL, embora continuem sendo escritas no elemento "SQL logic", precisarão de alguns ajustes de sintaxe. A linguagem SQL que você escreve por dentro agora segue o dialeto do PostgreSQL, que possui particularidades importantes.

Este brief vai te guiar pelas principais diferenças de sintaxe para que você possa escrever suas queries com confiança e evitar surpresas. Vamos cobrir desde a concatenação de strings até como lidar com buscas case e accent insensitive, além de outras mudanças fundamentais.

Nosso objetivo é garantir que a transição para o PostgreSQL seja suave e que você aproveite ao máximo o poder do ODC sem tropeços na camada de dados, mantendo suas aplicações rodando de forma eficiente e sem erros.

## Conceitos-chave

*   **Aurora PostgreSQL:** O novo banco de dados padrão no OutSystems Developer Cloud (ODC), exigindo adaptação da sintaxe SQL.
*   **Sintaxe SQL Divergente:** As diferenças cruciais em operadores, funções e cláusulas entre SQL Server/Oracle e PostgreSQL.
*   **`caseaccent_normalize()`:** Uma função essencial para realizar buscas case e accent insensitive (CIAI) em textos no PostgreSQL do ODC.
*   **`LIMIT`:** A cláusula padrão do PostgreSQL para limitar o número de registros retornados por uma consulta (substituindo o `TOP`).
*   **Operador `||`:** Utilizado para concatenação de strings no PostgreSQL, diferente do `+` usado em SQL Server.

## Exemplos práticos

Aqui estão alguns exemplos de como a sintaxe muda em cenários comuns do dia a dia:

*   **Busca Case/Accent Insensitive com `LIKE`:**
    *   **OutSystems 11 (SQL Server):**
        ```sql
        […] WHERE {Org}.[Name] LIKE '%asd%'
        ```
    *   **ODC (Aurora PostgreSQL):**
        ```sql
        […] WHERE caseaccent_normalize({Org}.[Name] collate "default") LIKE caseaccent_normalize('%asd%')
        ```

*   **Limitar o número de registros:**
    *   **OutSystems 11 (SQL Server):**
        ```sql
        SELECT TOP 10 * FROM {Organization}
        ```
    *   **ODC (Aurora PostgreSQL):**
        ```sql
        SELECT {Organization}.* FROM {Organization} LIMIT 10
        ```

*   **Concatenação de textos:**
    *   **OutSystems 11 (SQL Server):**
        ```sql
        […] WHERE {Org}.[Name] = 'First' + 'Last'
        ```
    *   **ODC (Aurora PostgreSQL):**
        ```sql
        […] WHERE {Org}.[Name] = 'First' || 'Last'
        ```

## Gotchas

*   **CUIDADO com LIKE, SIMILAR, REGEX!** Operadores de pattern matching como `LIKE`, `SIMILAR` e `REGEX` *não são suportados diretamente* com collations não determinísticas e causarão **erros em tempo de execução** no ODC. Sempre use a função `caseaccent_normalize()` com eles.
*   **`COLLATE "default"`:** Lembre-se de incluí-lo para colunas que têm collations não determinísticas (a maioria das colunas de texto criadas pelo ODC) ao usar `caseaccent_normalize()`. Para literais (ex: `'%algo%'`), ele pode ser omitido.
*   **Tipos de Dados:** Preste atenção à comparação de tipos como `TIME`. Pode ser necessário um cast explícito (`::time`) para garantir comparações corretas no PostgreSQL.
*   **Registros Aleatórios:** A função `NEWID()` do SQL Server para ordenação aleatória é substituída por `RANDOM()` em PostgreSQL, geralmente combinada com `LIMIT` para selecionar um número específico de registros.

## Duração estimada
1-2 minutos (SHORTS MODE — under 2 minutes) minutos quando falado em ritmo natural.

---