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 , आदि)।
मानक निर्दिष्ट अन्य चीजें अधिकांश विक्रेताओं द्वारा लागू नहीं की जाती हैं, इसलिए उनका उपयोग करना बहुत ही व्यर्थ है। सभी डीबी विक्रेताओं में एसक्यूएल-मानक जेनरेट और पहचान कॉलम का उपयोग करके शुभकामनाएँ।
"प्राथमिक वर्तनी" डंप मोड होना बहुत अच्छा होगा, जिसमें 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 कमेटी के पास एक और मस्तिष्क-गोज़ होता है और कुछ नया रचनात्मक बिट खींचता है वाक्य रचना का ... कहीं से। इसे बदलने के लिए बहुत सारे नए एक्सप्रेशन नोड प्रकार और सामान्य गड़बड़ी जोड़ने की आवश्यकता होगी, सभी बिना किसी वास्तविक लाभ के।
