Mike's questions

Para testes de compatibilidade, precisamos de uma lista completa de todos os tipos de dados disponíveis no MySQL v8.0, para garantir que um software de destino fora do ecossistema MySQL possa manipular corretamente todos os tipos de dados da fonte MySQL.

O ChatGPT me disse para tentar a seguinte consulta:

SELECT DISTINCT DATA_TYPE
FROM INFORMATION_SCHEMA.COLUMNS
ORDER BY DATA_TYPE;

Mas ele retorna apenas os tipos usados ​​na instância do MySQL à qual estamos nos conectando. Por exemplo, nossa consulta retornou 24 tipos, enquanto o ChatGPT me disse depois que o MySQL suporta 36 tipos no total.

Também consultamos o seguinte documento oficial online, mas ele não forneceu uma lista geral e também nos preocupamos que o documento possa não fornecer informações suficientes sobre a implementação.

• https://dev.mysql.com/doc/refman/8.0/en/data-types.html

Se quisermos descobrir isso programaticamente, dê-nos um exemplo.

Ou, se pudermos nos referir a um repositório de código aberto. Por favor, nos dê algumas dicas, pois não estamos familiarizados com os repositórios do mundo de código aberto.

Agradecemos muito quaisquer dicas e sugestões.

Temos um arquivo SQL despejado do PostgreSQL v10 pelo seguinte comando localmente no host:

pg_dump \
  "postgres://db_user:db_pass@localhost:5432/database" \
  --file "pgsql-dump-v10.sql" \
  --format=p --no-owner --no-privileges

Copiamos o arquivo de despejo para outro PostgreSQL da v16 e importamos os dados chamando o seguinte comando localmente:

psql \
  "postgresql://db_user:db_pass@localhost/database" \
  --file pgsql-dump-v10.sql

E, aparece a seguinte mensagem de erro:

psql:/xxx/pgsql-dump-v10.sql:30: ERRO: deve ser o proprietário da extensão plpgsql

E o culpado é a Linha 30, pssql-dump-v10.sqlcomo segue:

COMMENT ON EXTENSION plpgsql IS 'PL/pgSQL procedural language';

O erro não parece ser crítico, então chamamos o mesmo pg_dumpcomando na instância do PostgreSQL v16 e comparamos os dois dumps como na captura de tela abaixo.

Além disso, ao executar pgsql-dump-v16.sqlno PostgreSQL v16, não há nenhum erro.

Nossa pergunta:

Embora não seja crítico, queremos resolver o erro na configuração do comentário da extensão. E agradecemos muito quaisquer dicas e sugestões.

Além disso, se o erro realmente tiver mais impacto do que vimos, por favor, nos lembre também. Estamos nos preparando para uma operação de produção.

Obrigado.

Detalhes:

Estamos usando o PgAdmin conectando-se a uma instância do PostgreSQL.

Com o PgAdmin, no contexto de Servers > [the_server_login] > Databases > Create > Database, inserimos os parâmetros necessários, esperando permitir que o assistente gere o seguinte exemplo de SQL a partir de um documento.

CREATE DATABASE "Metabase_VM"
    WITH
    OWNER = metabase
    ENCODING = 'UTF8'
    LC_COLLATE = 'en_US.UTF-8'
    LC_CTYPE = 'en_US.UTF-8'
    TABLESPACE = pg_default
    CONNECTION LIMIT = -1
    IS_TEMPLATE = False;

No entanto, até agora, obtivemos apenas o seguinte SQL gerado:

CREATE DATABASE "Metabase_VM"
    WITH 
    OWNER = metabase
    ENCODING = 'UTF8'
    LC_COLLATE = 'en_US.UTF-8'
    LC_CTYPE = 'en_US.UTF-8'
    TABLESPACE = pg_default
    CONNECTION LIMIT = -1;

Nossas perguntas:

O SQL gerado atualmente está faltando IS_TEMPLATE = False, então onde na GUI podemos definir esse parâmetro?

Somos novos no PostgreSQL e no PgAdmin, por isso agradecemos muito quaisquer dicas e sugestões.

Com o MariaDB versão 10.1, estamos tentando converter um número inteiro em uma string, por exemplo, varchar(300). Consulte o exemplo de SQL abaixo para obter um exemplo minimizado.

A convert()função pode converter o número inteiro em um tipo de dados de comprimento fixo char(300), mas ocorre um erro reclamando da sintaxe se tentar converter para um tipo de dados de comprimento variável varchar(300).

A cast()função parece ter o mesmo comportamento.

Nossa pergunta:

Por que a função falha na conversão para varchar(300)? Se possível, como fazemos isso funcionar?

select version()
;
-- OK
-- 10.1.12-MariaDB

set @i = cast(1 as int);
-- OK

select @i
;
-- OK
-- 1

select convert(@i, char(300)   ) as col
;
-- OK
-- 1

select convert(@i, varchar(300)) as col
;
-- Error
/* SQL Error [1064] [42000]: (conn=284164) You have an 
error in your SQL syntax; check the manual that corresponds 
to your MariaDB server version for the right syntax to use 
near 'varchar(300)) as col
*/

select cast(@i as char(300)   ) as col
;
-- OK
-- 1

select cast(@i as varchar(300)) as col
;
-- Error
/* SQL Error [1064] [42000]: (conn=284164) You have an 
error in your SQL syntax; check the manual that corresponds 
to your MariaDB server version for the right syntax to use 
near 'varchar(300)) as col
*/

Ao desenvolver aplicativos analíticos de dados, a estação de trabalho precisa usar o MySQL-Proxy (versão 0.8) para se conectar à fonte de dados MySQL. Este método tem funcionado bem há anos, no entanto, notamos recentemente que a conexão não está mais funcionando.

A versão do MySQL é 5.7.43-47-log, entretanto, não temos cem por cento de certeza se foi devido à atualização da versão.

O problema está bloqueando nosso desenvolvimento, por isso agradecemos muito quaisquer dicas e sugestões.