आपने मैनुअल में मुख्य वाक्य को स्वयं बोल्ड किया है:
<ब्लॉकक्वॉट>SQL फ़ंक्शन के पूरे भाग को किसी भी कार्य के निष्पादित होने से पहले पार्स किया जाता है।
पार्सर चरण . के बारे में भी पढ़ें मैनुअल में।
इसमें दो प्रमुख भाग होते हैं:पार्सर और रूपांतरण प्रक्रिया . मैनुअल को उद्धृत करना:
<ब्लॉकक्वॉट>रूपांतरण प्रक्रिया पार्सर asinput द्वारा वापस सौंपे गए पेड़ को लेता है और यह समझने के लिए आवश्यक अर्थपूर्ण व्याख्या करता है कि क्वेरी द्वारा कौन से टेबल, फ़ंक्शंस और ऑपरेटरों को संदर्भित किया जाता है।
यदि किसी SQL फ़ंक्शन में ये कमांड हैं:
CREATE TABLE foo (...);
INSERT INTO foo VALUES(...);
दोनों बयानों की योजना लगभग एक ही समय (सिस्टम कैटलॉग के एक ही स्नैपशॉट के आधार पर) पर बनाई गई है। इसलिए, INSERT संभावित रूप से पिछले CREATE . के साथ बनाई गई तालिका "foo" नहीं देख सकता आज्ञा। इससे निम्न समस्याओं में से एक उत्पन्न होता है :
-
अगर कोई अन्य नहीं है आपके
search_patch. में "foo" नाम की तालिका (फिर भी), Postgres शिकायत करता है बनाने का प्रयास करते समय समारोह:ERROR: relation "foo" does not exist -
यदि आपके
search_patch. में "foo" नाम की कोई अन्य तालिका पहले से मौजूद है (और आप परस्पर विरोधी कॉलम नामों का उपयोग नहीं करते हैं), PostgresINSERT. की योजना बनाएंगे उस पूर्व-मौजूदा तालिका के आधार पर। आमतौर पर इसके परिणामस्वरूप निष्पादन समय पर त्रुटि होती है , यदि कोई मान (गलत!) तालिका में विरोध का कारण बनता है। या, कुछ दुर्भाग्य के साथ, यह बिना त्रुटि संदेश के उस तालिका में भी लिख सकता है! बहुत डरपोक बग।
PL/pgSQL . के साथ ऐसा नहीं हो सकता फ़ंक्शन, क्योंकि यह SQL कमांड को तैयार किए गए कथनों की तरह व्यवहार करता है, नियोजित और निष्पादित क्रमिक रूप से . इसलिए प्रत्येक कथन पिछले कथनों में बनाई गई वस्तुओं को देख सकता है।
नतीजतन, जिन बयानों का कभी दौरा नहीं किया जाता है, वे कभी भी योजनाबद्ध नहीं होते हैं - एसक्यूएल कार्यों के विपरीत। और कथनों के लिए निष्पादन योजना को उसी सत्र में कैश किया जा सकता है - SQL फ़ंक्शन के विपरीत भी। मैनुअल में PL/pgSQL फ़ंक्शंस में प्लान कैशिंग के बारे में विवरण पढ़ें।
प्रत्येक दृष्टिकोण में कुछ उपयोग के मामलों के फायदे हैं। आगे पढ़ना:
- PostgreSQL फ़ंक्शंस में भाषा sql और भाषा plpgsql के बीच अंतर
