O PostgreSQL Não Implementa o comando INSERT com a Cláusula SET

Você já utilizou a cláusula SET em um comando INSERT?  No postgresql, com certeza, não, pois a mesma não está implementada até a versão atual, a 9.3. Esta sintaxe pode ser descrita conforme aparece abaixo:

INSERT INTO nome_tabela SET coluna1 = expressão1, coluna2 = expressão2, .... ;

O fato é que esta sintaxe pouco acrescentaria em termos de valor. É pouco conhecida e pouco utilizada, embora eu acredite que esteja implementada em outros SGBDs. Sua funcionalidade seria idêntica à do comando INSERT já implementado, agregando possivelmente um pouco em termos de compatibilidade, embora não me recorde de ferramentas ou sistemas que utilizem esta sintaxe nas minhas andanças. 

Então porque estou comentando o fato do postgresql não implementar esta sintaxe?

Bom, justifico esta postagem por ter encontrado esta sintaxe em provas de concursos públicos, como nos exemplos abaixo. Não sei se a cláusula SET no INSERT faz parte do padrão ISO, mas não deixa de ser uma limitação, ainda que bem pequena.

Exemplos: 

Prova: FCC - 2012 - MPE-PE - Analista Ministerial - Informática

Disciplina: Banco de Dados | Assuntos: SQL;

Após a execução dos seguintes comandos SQL:

CREATE TABLE livros (id INT, nome TEXT);

INSERT INTO livros VALUES(1,'livro 1');

INSERT INTO livros (2,'livro 2');

INSERT INTO livros SET id=3,nome='livro 3';

SELECT id FROM livros;

O resultado da consulta para a coluna id será 

 

a) 3, apenas. b) 1, apenas. c) 1, 2 e 3. d) 2 e 3, apenas. e) 1 e 3, apenas.

Prova: FCC - 2012 - MPE-PE - Técnico Ministerial - Informática

Disciplina: Banco de Dados | Assuntos: SQL;

Analise os seguintes comandos em SQL:

CREATE TABLE nota (id INT PRIMARY KEY,data TEXT,valor REAL);

INSERT INTO nota SET id=1,data='01012012',valor=15.5;

INSERT INTO nota SET id=1,data='03022012',valor=11.5;

INSERT INTO nota SET id=2,data='01042012',valor=25.5;

INSERT INTO nota SET id=20,data='10062012',valor=12.5;

SELECT COUNT(*) FROM nota WHERE valor < 20;

O resultado para a consulta efetuada será: 

 

a) 12.5 b) 3 c) 11.5, 12.5 e 15.5 d) 2 e) 12.5 e 15.5

Esqueça o Comando SHOW: Use PG_SETTINGS

O comando SHOW é bastante utilizado para visualizar as configurações de um servidor PostgreSQL de datas, log, gerência de memória etc. Uma vez que na versão em que estou trabalhando tempos 187 parâmetros distintos, este comando se revela bastante prático para se ter uma visão geral da configuração e bem fácil de usar sem.
Abaixo, exemplos de sua sintaxe:

- SHOW ALL

- SHOW work_mem

No entanto, apresenta uma série de desagradáveis limitações:

- O resultado da consulta das variáveis de configuração não pode ser alterado (essa atualização pode ser feita pelo comando SET).
- Os campos mostrados são poucos e até insuficientes dependendo da necessidade (nome do parâmetro, valor corrente e descrição)
- Não é possível selecionar um subconjunto dados para ser visualizado (linhas e colunas), tampouco agregar colunas adicionais na consulta retornada.
- Não é possível montar consultas envolvendo junção, union e outros recursos da linguagem SQL.
- Para se visualizar 10 variáveis importantes, deve-se usar SHOW ALL ou fazer 10 comandos SHOW indicando as variáveis desejadas.

Apesar de sua utilizada, este comando simplesmente limita a flexibilidade de consultas e relatórios sobre as configurações do PostgreSQL. Como contornar esta limitação?

A tabela virtual PG_SETINGS contorna TODAS AS LIMITAÇÕES apresentadas pelo comando SHOW. As únicas restrições são:
- Não se pode inserir registros ou excluí-los (assim como não se pode adicionar e excluir variáveis de configuração)
- Certas variáveis não podem ser alteradas com o servidor em funcionamento ou apresentam restrições (como 'autovacuum' e 'bonjour_name', por exemplo).

As vantagens obtidas são várias:
- O resultado da consulta das variáveis de configuração pode ser alterado, respeitando-se as restrições de cada variável e seus valores aceitos .
- São mostradas mais informações sobre cada item de configuração (11 colunas)
- É possível selecionar um subconjunto dados para ser visualizado (utilizando comando SELECT!!!)
- É possível (e fácil) montar consultas envolvendo junção, union e outros recursos da linguagem SQL.
- Para se visualizar 10 (ou mais) variáveis importantes, pode ser empregado apenas um comando que retorne exclusivamente as variáveis desejadas.

Exemplos de utilização de PG_SETTINGS:

1 - Sintaxe básica, retornando todas as configurações.

SELECT * FROM pg_settings;

2 - Seleção de variáveis de configuração que comecem com 'AUTO'.

SELECT * FROM pg_settings WHERE NAME LIKE 'auto%';

3 - Consulta de variáveis de configuração com UNION.

SELECT * FROM pg_settings WHERE NAME LIKE 'auto%'
UNION
SELECT * FROM pg_settings WHERE NAME LIKE 'Date%';

4 - Consulta de variáveis de configuração com junção.

SELECT * FROM pg_settings p1, pg_settings p2
WHERE P1.NAME LIKE 'log_%' AND P1.NAME = P2.NAME AND UPPER(P2.UNIT) = 'KB';

Limitações: Configuração de Case Sensitivity and Accent Sensitivity

A partir de hoje colocarei à medida que forem surgindo, limitações que encontro no PostgreSQL. A primeira limitação a ser mencionada é a falta de uma configuração para Case Sensitivity e Accent Sensitivity no SGBD.

Case Sensitivity e Accent Sensitivity são características particularmente desejáveis nos bancos de dados atuais. A não existência de configuração para o armazenamento e/ou recuperação de dados com base nestas características é uma lacuna a ser preenchida neste banco de dados. Atualmente não há este recurso e as buscas de dados levando em conta ou não maiúsculas e minúsculas exigem alterações nas aplicações (com UPPER, LOWER, LIKE e ILIKE).

Uma consulta com Case Sensitivity (sensível ao caso) retorna valores levando em consideração se os caracteres buscados estão em maiúsculas ou minúsculas. Desta forma, a busca pelo valor 'CLA' retorna resultados diferentes da busca por 'Cla'. O não uso de sensitividade nas buscas de caracteres é chamado de Case Insensitivity.

Uma consulta com Accent Sensitivity (sensível ao acento) retorna valores levando em consideração se os caracteres buscados estão em maiúsculas ou minúsculas. Desta forma, a busca pelo valor 'CLA' retorna resultados diferentes da busca por 'Cla'. O não uso de sensitividade nas buscas de caracteres acentuados é chamado de Accent Insensitivity.

Proposta:

- A implementação de tal característica como configuração poderia ser feita para o banco todo, por tablespace, tabela ou visão, facilitando a implementação e evitando alterações nas aplicações mais complexas que necessitam destas funcionalidades.

- Poderia ser feita via comando SET e na criação de objetos do banco, como na de tabelas, indicando que colunas são SENSITIVE e INSENSITIVE.

- O padrão deve ser INSENSITIVE por questões de desempenho.

Ressalvas:

- Novas propostas para esta funcionalidade são bem vindas e podem ser colocadas no comentário deste post.