PostgreSQL няма такава функция. Дори и да го направи, няма да ви помогне много, защото интерпретациите на SQL стандарта варират, поддръжката за стандартен синтаксис и функции варира, а някои DB са спокойни по отношение на ограниченията, които други налагат, или имат ограничения, други не. Синтаксисът е най-малкият ви проблем.
Единственият надежден начин за писане на преносим SQL между DB е да се тества този SQL във всяка целева база данни като част от автоматизиран тестов пакет . И да псувам много.
На много места анализаторът/преписвачът на заявки трансформира стандартното „изписване“ на заявка във вътрешната форма на PostgreSQL, която ще бъде излъчена при дъмп/презареждане. По-специално, PostgreSQL не съхранява необработения изходен код за неща като изгледи, изрази за ограничения за проверка, изрази за индексиране и т.н. Той съхранява вътрешното дърво за анализ и възстановява източника от него, когато бъде помолен да изведе или покаже обекта.
Например:
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)
Така или иначе би било доста безполезно, тъй като стандартът не успява да посочи някои доста общи и важни части от функционалността и често има доста двусмислени спецификации на нещата, които дефинира. Доскоро не дефинираше начин за ограничаване на броя на редовете, върнати от заявка, например, така че всяка база данни имаше свой собствен различен синтаксис (TOP , LIMIT / OFFSET и т.н.).
Други неща, които стандартът определя, не се прилагат от повечето доставчици, така че използването им е доста безсмислено. Успех с използването на генерираните от SQL стандарт колони и колони за идентичност във всички доставчици на DB.
Би било доста хубаво да има режим на дъмп „предпочитам стандартен правопис“, който използва CAST вместо :: , и т.н., но наистина не е лесно да се направи, защото някои трансформации не са 1:1 обратими, напр.:
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));
или:
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;
така че виждате, че ще трябва да се направят значителни промени в начина, по който PostgreSQL вътрешно представя и работи с функции и изрази, преди да стане възможно това, което искате.
Много от стандартните SQL неща използват забавен еднократен синтаксис, който PostgreSQL преобразува в извиквания на функции и прехвърляния по време на синтактичен анализ, така че не се налага да добавя функции за специални случаи всеки път, когато SQL комитетът има нов мозъчен удар и извади някакъв нов творчески бит на синтаксиса от ... някъде. Промяната на това ще изисква добавяне на тонове нови типове изразни възли и обща бъркотия, всичко това без реална печалба.
