No Postgres, estou procurando uma maneira de identificar exclusivamente uma tabela, independentemente das alterações de nome. OIDs parecem aptos para isso. Mas os OIDs terminam após 2 ^ 32-1.
Se os OIDs forem encapsulados, posso obter duas tabelas com o mesmo OID em pg_class? Ou há algo que o impeça?
Na documentação do PG 14, na CREATE FUNCTIONseção, o manual diz que o corpo de uma LANGUAGE SQLfunção pode ser uma única declaração:
RETURN expression
ou um bloco:
BEGIN ATOMIC
statement;
statement;
...
statement;
END
sem dar qualquer explicação sobre a semântica desse bloco. Isso se parece com um BEGIN ... END;bloco em PL/pgSQL, mas parece ser algo diferente.
Qual é a diferença entre escrever um conjunto de instruções dentro ou sem BEGIN ATOMIC ... END? Quando é necessário usar tal bloco? A ATOMICpalavra-chave é obrigatória?
Na documentação do PG 13, há vários exemplos de agrupamentos de UTI para fins especializados. Também é mencionado que existem localidades ICU que permitem criar agrupamentos para ignorar acentos e que podem ser encontrados em https://github.com/unicode-org/cldr/blob/master/common/bcp47/collation.xml
No entanto, depois de ler esse documento, ainda não tenho certeza sobre qual é a localidade que devo usar para criar um agrupamento ICU para comparações insensíveis ao sotaque em espanhol.
Qual é o nome de tal localidade de UTI? Existe alguma lista de agrupamentos em espanhol da UTI?
Eu quero os lexemas de um array tsvector colocado em uma coluna, um por linha. Eu posso primeiro desaninhar a matriz e depois os tsvectors resultantes com:
SELECT (unnest(unnest(my_array))).lexeme
FROM my_table
WHERE id = 1;
que dá:
lexeme
----------
foo
bar
baz
...
Percebi, no entanto, que se eu tentar fazer o mesmo na cláusula FROM:
SELECT lexeme
FROM unnest(
(SELECT unnest(my_array) FROM my_table WHERE id = 1)
);
Eu recebo:
ERRO: mais de uma linha retornada por uma subconsulta usada como expressão
Então, eu acabo fazendo isso:
SELECT lexeme
FROM (
SELECT (unnest(col1)).lexeme
FROM (
SELECT unnest(my_array)
FROM my_table
WHERE id = 1
) AS t(col1)
) AS t2;
E eu recebo o resultado original. Mas isso é verboso. Então, gostaria de saber:
Por que unnest() requer uma única linha de entrada na cláusula FROM, mas não na cláusula SELECT?
Existe uma maneira mais concisa e menos complicada do que meu código para obter a coluna de lexemas na cláusula FROM?
Existe uma diferença de desempenho entre desaninhar na cláusula SELECT versus fazê-lo na cláusula FROM?
O seguinte é um trecho de um livro sobre design de banco de dados (Beginning Database Design ISBN: 0-7645-7490-6):
O perigo de usar visualizações é filtrar uma consulta em uma visualização, esperando ler uma parte muito pequena de uma tabela muito grande. Qualquer filtragem deve ser feita na exibição porque qualquer filtragem na própria exibição é aplicada depois que a consulta na exibição conclui a execução. As exibições geralmente são úteis para acelerar o processo de desenvolvimento, mas, a longo prazo, podem matar completamente o desempenho do banco de dados.
O seguinte é um trecho da documentação do PostgreSQL 9.5:
Fazer uso liberal de visualizações é um aspecto fundamental do bom design de banco de dados SQL. As visualizações permitem encapsular os detalhes da estrutura de suas tabelas, que podem mudar à medida que seu aplicativo evolui, por trás de interfaces consistentes.
As duas fontes parecem se contradizer ("não projete com vistas" vs. "faça design com vistas").
No entanto, nas visualizações PG são implementadas usando o sistema de regras. Portanto, possivelmente (e esta é a minha pergunta) qualquer filtragem na exibição é reescrita como um filtro na exibição, resultando em uma única execução de consulta nas tabelas subjacentes.
Minha interpretação está correta e o PG combina cláusulas WHERE dentro e fora da visão? Ou ele os executa separadamente, um após o outro? Algum exemplo curto, autocontido, correto (compilável)?