O PostgreSQL não possui esse recurso. Mesmo que isso acontecesse, não ajudaria muito porque as interpretações do padrão SQL variam, o suporte para a sintaxe e os recursos padrão variam e alguns bancos de dados são relaxados sobre restrições que outros impõem ou têm limitações que outros não. A sintaxe é o menor dos seus problemas.
A única maneira confiável de escrever SQL portátil entre bancos de dados é testar esse SQL em cada banco de dados de destino como parte de um conjunto de testes automatizado . E jurar muito.
Em muitos lugares, o analisador/reescritor de consulta transforma a "ortografia" padrão de uma consulta no formulário interno do PostgreSQL, que será emitido no dump/reload. Em particular, o PostgreSQL não armazena o código-fonte bruto para coisas como visualizações, expressões de restrição de verificação, expressões de índice, etc. Ele armazena a árvore de análise interna e reconstrói a fonte a partir dela quando é solicitado a despejar ou exibir o objeto.
Por exemplo:
regress=> CREATE TABLE sometable ( x varchar(100) );
CREATE TABLE
regress=> CREATE VIEW someview AS SELECT CAST (x AS integer) FROM sometable;
CREATE VIEW
regress=> SELECT pg_get_viewdef('someview');
pg_get_viewdef
-------------------------------------
SELECT (sometable.x)::integer AS x
FROM sometable;
(1 row)
Seria bastante inútil de qualquer maneira, já que o padrão falha em especificar algumas peças de funcionalidade bastante comuns e importantes e geralmente tem especificações bastante ambíguas das coisas que define. Até recentemente não definia uma forma de limitar o número de linhas retornadas por uma consulta, por exemplo, então cada banco de dados tinha sua própria sintaxe diferente (
TOP , LIMIT / OFFSET , etc). Outras coisas que o padrão especifica não são implementadas pela maioria dos fornecedores, portanto, usá-las é bastante inútil. Boa sorte usando as colunas de identidade e geradas pelo padrão SQL em todos os fornecedores de banco de dados.
Seria muito bom ter um modo de despejo "preferir ortografia padrão", que usasse
CAST em vez de :: , etc, mas realmente não é simples de fazer porque algumas transformações não são 1:1 reversíveis, por exemplo:regress=> CREATE VIEW v AS SELECT '1234' SIMILAR TO '%23%';
CREATE VIEW
regress=> SELECT pg_get_viewdef('v');
SELECT ('1234'::text ~ similar_escape('%23%'::text, NULL::text));
ou:
regress=> CREATE VIEW v2 AS SELECT extract(dow FROM current_date);
CREATE VIEW
regress=> SELECT pg_get_viewdef('v2');
SELECT date_part('dow'::text, ('now'::text)::date) AS date_part;
então você vê que mudanças significativas precisariam ser feitas na forma como o PostgreSQL representa e trabalha internamente com funções e expressões antes que o que você deseja seja possível.
Muitas das coisas padrão do SQL usam uma sintaxe única que o PostgreSQL converte em chamadas de função e lança durante a análise, então ele não precisa adicionar recursos de caso especiais toda vez que o commit do SQL tiver outro peido cerebral e puxar algum novo pedaço criativo de sintaxe de ... em algum lugar. Mudar isso exigiria a adição de toneladas de novos tipos de nós de expressão e confusão geral, tudo sem nenhum ganho real.
