PostgreSQL no tiene tal característica. Incluso si lo hiciera, no le ayudaría mucho porque las interpretaciones del estándar SQL varían, el soporte para la sintaxis estándar y las funciones varían, y algunos DB no tienen restricciones sobre las restricciones que otros imponen o tienen limitaciones que otros no tienen. La sintaxis es el menor de tus problemas.
La única forma confiable de escribir SQL portátil entre bases de datos es probar ese SQL en cada base de datos de destino como parte de un conjunto de pruebas automatizado . Y jurar mucho.
En muchos lugares, el analizador/reescritor de consultas transforma la "ortografía" estándar de una consulta en el formato interno de PostgreSQL, que se emitirá en el volcado/recarga. En particular, PostgreSQL no almacena el código fuente sin procesar para cosas como vistas, expresiones de restricción de verificación, expresiones de índice, etc. Almacena el árbol de análisis interno y reconstruye la fuente a partir de eso cuando se le solicita volcar o mostrar el objeto.
Por ejemplo:
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)
Sería bastante inútil de todos modos, ya que el estándar no especifica algunas piezas de funcionalidad bastante comunes e importantes y, a menudo, tiene especificaciones bastante ambiguas de las cosas que define. Hasta hace poco, no definía una forma de limitar el número de filas devueltas por una consulta, por ejemplo, por lo que cada base de datos tenía su propia sintaxis diferente (TOP , LIMIT / OFFSET , etc.).
La mayoría de los proveedores no implementan otras cosas que especifica el estándar, por lo que su uso es bastante inútil. Buena suerte al usar las columnas de identidad y generadas por el estándar SQL en todos los proveedores de bases de datos.
Sería muy bueno tener un modo de volcado de "ortografía estándar preferida", que usara CAST en lugar de :: , etc., pero en realidad no es fácil de hacer porque algunas transformaciones no son reversibles 1:1, por ejemplo:
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));
o:
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;
por lo tanto, verá que se deben realizar cambios significativos en la forma en que PostgreSQL representa internamente y funciona con funciones y expresiones antes de que sea posible lo que desea.
Muchas de las cosas estándar de SQL utilizan una sintaxis original única que PostgreSQL convierte en llamadas a funciones y se convierte durante el análisis, por lo que no tiene que agregar funciones de casos especiales cada vez que el comité de SQL tiene otro pedo cerebral y saca un poco de creatividad nueva. de sintaxis de ... en alguna parte. Cambiar eso requeriría agregar toneladas de nuevos tipos de nodos de expresión y desorden general, todo sin una ganancia real.
