PostgreSQL wymusza standardową składnię SQL

PostgreSQL nie ma takiej funkcji. Nawet gdyby tak było, nie pomogłoby to wiele, ponieważ interpretacje standardu SQL są różne, obsługa standardowej składni i funkcji jest różna, a niektóre bazy danych są zrelaksowane w zakresie ograniczeń, które inni wymuszają lub mają ograniczenia, których nie mają inni. Składnia to najmniejszy z twoich problemów.

Jedynym niezawodnym sposobem napisania przenośnego SQL między bazami danych jest testowanie tego SQL w każdej docelowej bazie danych w ramach zautomatyzowanego zestawu testów . I dużo przeklinać.

W wielu miejscach parser/przepisujący zapytanie przekształca standardową "pisownię" zapytania na wewnętrzny formularz PostgreSQL, który będzie emitowany podczas zrzutu/przeładowania. W szczególności PostgreSQL nie przechowuje surowego kodu źródłowego dla takich rzeczy jak widoki, wyrażenia ograniczające sprawdzanie, wyrażenia indeksujące itp. Przechowuje wewnętrzne drzewo analizy i rekonstruuje źródło z tego, gdy jest proszony o zrzucenie lub wyświetlenie obiektu.

Na przykład:

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)

I tak byłoby to całkiem bezużyteczne, ponieważ standard nie określa dość powszechnych i ważnych elementów funkcjonalności i często ma raczej niejednoznaczne specyfikacje rzeczy, które definiuje. Do niedawna nie definiował na przykład sposobu na ograniczenie liczby wierszy zwracanych przez zapytanie, więc każda baza danych miała swoją własną składnię (TOP , LIMIT / OFFSET itp.).

Inne rzeczy, które określa standard, nie są implementowane przez większość dostawców, więc używanie ich jest dość bezcelowe. Powodzenia w korzystaniu ze standardowych kolumn SQL i kolumn tożsamości u wszystkich dostawców baz danych.

Byłoby całkiem miło mieć tryb zrzutu „preferuj standardową pisownię”, który używał CAST zamiast :: itp., ale nie jest to łatwe, ponieważ niektóre przekształcenia nie są odwracalne w stosunku 1:1, np.:

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));

lub:

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;

więc widzisz, że musiałyby zostać wprowadzone znaczące zmiany w sposobie, w jaki PostgreSQL wewnętrznie reprezentuje i współpracuje z funkcjami i wyrażeniami, zanim to, co chcesz, będzie możliwe.

Wiele standardowych rzeczy SQL wykorzystuje ciekawą, jednorazową składnię, którą PostgreSQL konwertuje na wywołania funkcji i rzutuje podczas parsowania, więc nie ma potrzeby dodawania specjalnych funkcji dotyczących wielkości liter za każdym razem, gdy komitet SQL ma kolejny pierdnięcie mózgu i wyciąga nowe kreatywne elementy składni z ... gdzieś. Zmiana, która wymagałaby dodania ton nowych typów węzłów wyrażeń i ogólnego bałaganu, a wszystko to bez realnego zysku.