PostgreSQL non ha tale funzionalità. Anche se lo facesse, non ti aiuterebbe moltissimo perché le interpretazioni dello standard SQL variano, il supporto per la sintassi e le funzionalità standard variano e alcuni DB sono rilassati sulle restrizioni che altri impongono o hanno limitazioni che altri no. La sintassi è l'ultimo dei tuoi problemi.
L'unico modo affidabile per scrivere SQL portatile su più DB è testare quell'SQL su ogni database di destinazione come parte di una suite di test automatizzata . E giurare molto.
In molti punti il parser/rewriter di query trasforma l'"ortografia" standard di una query nel modulo interno di PostgreSQL, che verrà emesso durante il dump/reload. In particolare, PostgreSQL non memorizza il codice sorgente non elaborato per cose come viste, espressioni di vincoli di controllo, espressioni di indice, ecc. Memorizza l'albero di analisi interno e ricostruisce il sorgente da quello quando gli viene chiesto di scaricare o visualizzare l'oggetto.
Ad esempio:
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)
Sarebbe comunque abbastanza inutile, dal momento che lo standard non specifica alcune funzionalità piuttosto comuni e importanti e spesso ha specifiche piuttosto ambigue di cose che definisce. Fino a poco tempo fa non definiva un modo per limitare il numero di righe restituite da una query, ad esempio, quindi ogni database aveva una propria sintassi diversa (TOP , LIMIT / OFFSET , ecc).
Altre cose specificate dallo standard non sono implementate dalla maggior parte dei fornitori, quindi usarle è piuttosto inutile. Buona fortuna per l'utilizzo delle colonne di identità e generate dallo standard SQL in tutti i fornitori di database.
Sarebbe molto carino avere una modalità di dump "preferisci l'ortografia standard", che utilizzava CAST invece di :: , ecc, ma non è davvero semplice da fare perché alcune trasformazioni non sono 1:1 reversibili, ad esempio:
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));
oppure:
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;
quindi vedi che dovrebbero essere apportate modifiche significative al modo in cui PostgreSQL rappresenta internamente e funziona con funzioni ed espressioni prima che ciò che desideri sia possibile.
Molte delle cose standard SQL utilizzano una sintassi originale che PostgreSQL converte in chiamate di funzione e cast durante l'analisi, quindi non è necessario aggiungere funzionalità di casi speciali ogni volta che il comitato SQL ha un'altra scoreggia cerebrale e tira qualche nuovo bit creativo di sintassi fuori... da qualche parte. La modifica richiederebbe l'aggiunta di tonnellate di nuovi tipi di nodi di espressione e confusione generale, il tutto senza alcun reale guadagno.
