MERGE की लड़ाई। निष्कर्ष और नैतिकता के साथ क्रॉनिकल

महत्वपूर्ण प्रतिबद्ध त्यौहार से कुछ हफ्ते पहले - पोस्टग्रेएसक्यूएल 11 के feature freeze संस्करण से पहले - हैकर्स न्यूज़लेटर्स, बाएं पैकेज में चिपसेट को संपीड़ित करते हुए, MERGE थ्रिलर देखा। थ्रिलर निर्देशक और 2ndQuadrant के सीईओ , साइमन रिग्स , ने एक पैच को धक्का देने की कोशिश की जो MERGE कमांड के सिंटैक्स को प्रभावशाली दृढ़ता और सरलता के साथ लागू करता है। रिग्स 2009 से एक कॉमेडियन हैं, और एक कॉमेडियन की स्थिति के साथ आप अपने आप को पैच अपीयर कर सकते हैं। वह कोई कम सम्मानित PostgreSQL समितियों और दिग्गजों द्वारा विरोध किया गया था। जुनून स्पष्ट रूप से और स्पष्ट रूप से उभर रहे थे, यह सीधे अपमान भी नहीं आया था - कई घरेलू मंचों में नियमित रूप से आश्चर्यजनक तथ्य। हालाँकि, कुछ तनाव तब तक बना रहा जब सवाल सुलझा लिया गया था, और इसके बारे में बहस करने के लिए कुछ भी नहीं है।

लेकिन जुनून जुनून हैं (उनकी आगे चर्चा की जाएगी), और मैं इस पूरी तरह से दूर की समस्या के सार को अलग-अलग करना चाहूंगा।

बाहर की तरफ

यदि यह पूरी तरह से सरल है, तो बात यह है: हमारे पास एक ही फ़ील्ड और विभिन्न डेटा के साथ 2 टेबल हैं। नाम और आयु मान लें। हमें उन्हें एक में मिलाने की जरूरत है। लेकिन यह तय करना आवश्यक होगा कि उन व्यक्तित्वों के साथ क्या करना है जो दोनों तालिकाओं में हैं। सबसे अधिक संभावना है कि हम अंतिम तालिका में सब कुछ चाहते हैं, और मिलान वाले व्यक्तियों को जानकारी अपडेट करेंगे। यह स्पष्ट है कि इस सेटिंग में भी यह एक बहुत ही सामान्य कार्य है। यह MERGE बिना हल किया जा सकता है, एक जटिल अनुरोध करते हुए, आप ट्रिगर्स और इतने पर उपयोग कर सकते हैं। लेकिन यह असुविधाजनक है। हालाँकि, MERGE का गैर-विहित संस्करण, जिसे UPSERT (UPdate + inSERT) कहा जाता है, इस समस्या को हल करता है।

MERGE ऑपरेटर SQL-2003 मानक में है और पहले से ही SQL-2008 में अपनी सभी महिमा में है। इसे Oracle, DB2 और MS SQL में लागू किया गया है, जिसका अर्थ है MERGE की कमी उन लोगों को परेशान करेगी जो इन DBMSs से PostgreSQL में जाने पर विचार कर रहे हैं। साइमन रिग्स की लालसा की इच्छा जितनी जल्दी हो सके, पहले से ही PostgreSQL 11 में, 2ndQuadrant ग्राहकों की इच्छाओं के अनुसार, और महत्वाकांक्षा या झगड़े से नहीं।

वास्तव में, MERGE में समृद्ध क्षमताएं हैं, डेटा को तालिकाओं से नहीं लेना पड़ता है, खासकर संरचना में समान लोगों से।

कमांड सिंटैक्स निम्नानुसार है:

  MERGE INTO tablename USING table_reference ON (condition) WHEN MATCHED THEN UPDATE SET column1 = value1 [, column2 = value2 ...] WHEN NOT MATCHED THEN INSERT (column1 [, column2 ...]) VALUES (value1 [, value2 ...]); 

हालाँकि, आप इसे पसंद कर सकते हैं:

 MERGE [hint] INTO [schema .] {table | view} [table_alias] USING { subquery | [schema .] { table | view}} [table_alias] ON ( condition ) [ merge_update_clause ] [ merge_insert_clause ] [ error_logging_clause ] ; 

यह सिंटैक्स ओरेकल में लागू किया गया है। शब्दों में, तब MERGE क्रियाएँ करता है जो एक ही SQL कमांड में data_source का उपयोग करके लक्ष्य तालिका में रिकॉर्ड को संशोधित करता है target_table_name, जो शर्तों के अनुसार, INSERT, UPDATE या DELETE को target_table_name में रिकॉर्ड के संबंध में कर सकता है। इस मामले में, target_table_name एक दृश्य हो सकता है, और data_source तालिकाओं या विचारों का एक सेट हो सकता है , एक सबक्वेरी का परिणाम हो सकता है ।

सबसे पहले, MERGE , data_source पर data_source साथ एक left outer join करता है, जिसमें 0 या अधिक कैंडिडेट चेंज रिकॉर्ड्स का सुझाव दिया गया है; निर्दिष्ट क्रम में गणना WHEN जाती है; जैसे ही स्थिति संतुष्ट होती है, संबंधित कार्रवाई की जाती है। WHEN [NOT] MATCH THEN SQL में कीवर्ड WHEN [NOT] MATCH THEN , तो यह बहुत सामान्य नहीं होता है, इसलिए हम आपको याद दिलाते हैं कि यह एक नियंत्रण निर्माण है जैसे if-else अन्य भाषाओं में। MERGE उसी तरह से कार्य करता है जैसे कि UPDATE, INSERT या DELETE target_table_name संबंध में है, केवल पूरे कमांड का सिंटैक्स अलग है।

ON साथ एक क्लॉज़ को प्राथमिक कुंजी के सभी स्तंभों पर एक कनेक्शन बनाना चाहिए या, यदि अन्य कॉलम निर्दिष्ट किए जाते हैं, तो कुछ अद्वितीय सूचकांक का उपयोग किया जाना चाहिए, ताकि अन्य लेनदेन के साथ सहभागिता को बाहर करने के लिए [NOT] MATCHED तुरंत उम्मीदवार रिकॉर्ड के लिए क्रियाओं का निर्धारण करें।

MERGE निर्धारक कमांड: आप एक ही रिकॉर्ड को एक ही MERGE कमांड में कई बार अपडेट नहीं कर सकते।
एक उदाहरण:

 MERGE CustomerAccount CA USING RecentTransactions T ON T.CustomerId = CA.CustomerId WHEN MATCHED THEN UPDATE SET Balance = Balance + TransactionValue WHEN NOT MATCHED THEN INSERT (CustomerId, Balance) VALUES (T.CustomerId, T.TransactionValue); 

या एक उपश्रेणी के साथ:

 MERGE INTO bonuses D USING (SELECT employee_id, salary, department_id FROM employees WHERE department_id = 80) S ON (D.employee_id = S.employee_id) WHEN MATCHED THEN UPDATE SET D.bonus = D.bonus + S.salary*.01 DELETE WHERE (S.salary > 8000) WHEN NOT MATCHED THEN INSERT (D.employee_id, D.bonus) VALUES (S.employee_id, S.salary*.01) WHERE (S.salary <= 8000); 

IBM DB2 में, सिंटैक्स भी काम करेगा। जैसा कि वे कहते हैं , "हुड के नीचे" यह समान रूप से UPDATE FROM निर्माण UPDATE FROM किया जाएगा।
2008 से, MS SQL में MERGE भी है ।

लेकिन एकल, मानक सिंटैक्स के पीछे भी, काफी संख्या में तंत्र और कार्यान्वयन विधियों से चुनने की समस्या शुरू होती है। टीम को अलग-अलग लॉकिंग एल्गोरिदम के साथ लेन-देन अलगाव के विभिन्न स्तरों पर काम करना चाहिए, अत्यधिक प्रतिस्पर्धी या ऑपरेशन के मोड पर ध्यान केंद्रित नहीं करना चाहिए। और, जैसा कि आप अनुमान लगा सकते हैं, इस जटिल तर्क को लागू करने के लिए, आपको बहुत सारे डीबीएमएस घटकों को छूने की आवश्यकता है।

यूपीएसईआरटी, स्यूडो-मेरेज

यह स्पष्ट है कि DBMS डेवलपर्स समझौता समाधानों की तलाश कर रहे थे, सचमुच मानक सिंटैक्स को पुन: पेश करने से इनकार कर रहे थे। इस दृष्टिकोण का प्लस स्वतंत्रता है। आप उन तंत्रों का उपयोग कर सकते हैं जो किसी विशेष DBMS के लिए जैविक हैं, आप उन कार्यों के लिए कार्यान्वयन को अनुकूलित कर सकते हैं जिन्हें आप अपने उपयोगकर्ताओं के लिए सबसे अधिक प्रासंगिक मानते हैं।

उदाहरण के लिए, MySQL में एक REPLACE कमांड है जो INSERT रूप में काम करता है, लेकिन यदि नई और पुरानी पंक्तियों में PRIMARY KEY या UNIQUE इंडेक्स में समान मान हैं, तो नया डालने से पहले पुरानी पंक्ति को मार दिया जाता है। लेकिन INSERT ... ON DUPLICATE KEY UPDATE जहाँ INSERT और UPDATE होते हैं (बजाय REPLACE में DELETE )। यह UPSERT । और INSERT IGNORE , जो टारगेट टेबल पर कुछ प्रतिबंधों के तहत एक त्रुटि (लेकिन चेतावनी) फेंकने के बिना, केवल प्रविष्टि नहीं करता है।

PG MERGE का इतिहास

PostgreSQL समुदाय में, MERGE के बारे में बात 2005 में शुरू हुई जब Jaime Casanova ने पूछा कि क्या समुदाय में किसी ने MERGE विकसित करना शुरू कर दिया है । पीटर एसेन्ट्रौट ने चर्चा करने का सुझाव दिया कि क्या PostgreSQL को MERGE विकल्पों में से एक को विकसित करना चाहिए: MySQL कार्यान्वयन के समान, या Oracle से MERGE प्रकार के कार्यात्मक हल्के संस्करण के लिए प्रयास को निर्देशित करने के लिए बेहतर है। हालाँकि, क्या इस दिशा में प्रयास करना उचित है?

एक छोटी चर्चा के बीच में, इस कथा के नायक साइमन रिग्स शब्द के साथ दिखाई देते हैं:
MERGE, OLTP सिस्टम के लिए और DW (डेटा वेयरहाउस - डेटा वेयरहाउस, यानी विश्लेषणात्मक एप्लिकेशन, जहाँ जटिल प्रश्न हैं, लेकिन बहुत प्रतिस्पर्धात्मक वातावरण और डेटा शायद ही अपडेट नहीं किया जाता है, और यदि वे अपडेट किए जाते हैं, तो आमतौर पर बड़ी मात्रा में <> <>> दोनों के लिए उपयोगी है।) हम MERGE को COPY FROM के एक संस्करण के रूप में लागू कर सकते हैं, यह बहुत अच्छा होगा।

सभी सहमत हैं: हाँ, अच्छा है। अधिक सटीक रूप से, लगभग सब कुछ: स्टीफन फ्रॉस्ट : मुझे लगता है कि मैं केवल एक ही ऐसा व्यक्ति नहीं हूं जो कहता है कि मुझे एक पूर्ण, आज्ञाकारी MERGE मानक की आवश्यकता है।

ब्रूस मोम्जियन के पास एक अलग, अधिक व्यावहारिक प्रस्ताव है: यह मुझे लगता है कि हमें MERGE में लागू करने की आवश्यकता है कुछ विकल्प जिन्हें हम लागू कर सकते हैं, और बाकी में हम एक त्रुटि देंगे (और उन मामलों में जहां पूरी तालिका को ब्लॉक करना आवश्यक होगा)। और हम उपयोगकर्ताओं से प्रतिक्रिया प्राप्त करने के बाद और हम सोचेंगे कि आगे क्या करना है।

लेकिन अभी तक कुछ नहीं हो रहा है।

बर्फ टूट चुकी है

2008 में, साइमन रिग्स ने फिर से MERGE से निपटने का आग्रह किया - चुनने के लिए कौन से तरीके (तब तक SQL-2008 मानक में MERGE का एक नया संस्करण, जो अभी भी मसौदा है, पहले से ही दिखाई दे रहा है)। वह उस समय ओरेकल, आईबीएम और एमएस SQL ​​के कार्यान्वयन और MySQL और Teradata से वैकल्पिक वाक्यविन्यास में विस्तार से पेंट करता है। और थोड़ी देर बाद वह पहले से ही इस दिशा में 2ndQuadrant में काम की शुरुआत का उल्लेख करता है।

पीटर आइसेनट्राट अपने ब्लॉग पर लिखते हैं : बेशक, रिग्स सबसे योग्य विशेषज्ञों में से एक हैं, वह MERGE के कार्यान्वयन पर काम का नेतृत्व कर सकते हैं।

लेकिन यहां पहला अप्रत्याशित मोड़ आता है: एक छात्र समस्या में शामिल है - जीएसओसी कार्यक्रम के विकास में एक भागीदार, यानी कोड का Google ग्रीष्मकालीन। उसका नाम बॉक्सुआन Bxzhai है - मैं अंतिम नाम को स्थानांतरित करने के लिए नहीं मानता हूं। जल्द ही वह लिखते हैं कि काम लगभग पूरा हो गया है।

लेकिन लगभग गिनती नहीं है। 2ndQuadrant के ग्रेग स्मिथ (यानी साइमन रिग्स सहयोगी) लिखते हैं:
तो, हमारे पास एक कोड है जिसमें आधा दर्जन गंभीर अनसुलझे समस्याएं हैं। मैं क्षुद्र लोगों के बारे में चुप हूँ। कमेटी के लिए कोड को अंतिम रूप देने के लिए समस्याएं बहुत गहरी हैं। इस बीच, लंबे समय से बॉक्सुआन से कुछ भी नहीं सुना गया है। हम उसकी मदद कर सकते थे, लेकिन वह कहां है? किसमें है जान?

2014 में कार्यान्वयन पथों की चर्चा फिर से भड़की , लेकिन फिर कुछ नहीं हुआ: कोई कोड नहीं है।

अंत में, 2017 की शुरुआत में , साइमन रिग्स लिखते हैं:
मैं MERGE को PostgreSQL संस्करण 11 के लिए प्रतिबद्ध करने के लिए कोड पर काम कर रहा हूं। हम उसी तंत्र का उपयोग करते हैं जो पहले से ही काम कर रहे INSERT ON CONFLICT रेखांकित करता है, ताकि किसी बुनियादी ढाँचे में बदलाव की आवश्यकता न हो, मूल रूप से जो उपलब्ध है उसके ऊपर सिंटैक्स लागू करना। लेकिन मैं खरोंच से अपना कोड लिखता हूं, मैं पिछले विकास का उपयोग नहीं करता हूं।

हम बात कर रहे हैं पीटर जोगेगन ( वीएमवेयर ) की, जो तब तक लागू हो चुका था, पहले से ही 9.5 वैकल्पिक INSERT .. ON CONFLICT UPDATE सिंटैक्स पर, SQL मानक से अलग, लेकिन फिर भी MySQL में MERGE और REPLACE से संबंधित है।

सबसे पहले, साइमन का काम नीस के काम के उद्गार से मिला था! हालांकि, रॉबर्ट हास , हालांकि सहायक हैं, संभावित क्रमिक विसंगतियों की चेतावनी देते हैं। जैसे, INSERT .. ON CONFLICT UPDATE से निपटने के लिए INSERT .. ON CONFLICT UPDATE , इसके आधार पर MERGE के बिना, यह किसी भी तरह से शांत है।

PostgreSQL UPSERT लेखक UPSERT खुद:
मैं ON CONFLICT DO UPDATE और MERGE को नहीं ON CONFLICT DO UPDATE । <...> बड़ी मात्रा में डेटा लोड करने के लिए ( bulk load ), उदाहरण के लिए, merge join एल्गोरिथम का उपयोग करें। <...> सामान्य तौर पर, MERGE के फायदे इस तथ्य से संबंधित होंगे कि सामान्य कनेक्शन वहां सामान्य तरीके से काम करेंगे: nested loop, hash, merge । और INSERT … ON CONFLICT कोई INSERT … ON CONFLICT नहीं हैं।

हास: पीटर की तरह, मुझे लगता है कि अगर इस तरह से किया जाता है, तो DML अनुरोध निष्पादित करते समय ऐसा मजबूत लॉक ऐसा लगता है। यह संभावना नहीं है कि कोई भी प्रसन्न होगा कि एक समय में केवल एक ही व्यक्ति MERGE साथ काम कर सकता है।

जिज्ञासु के लिए: गीगन MERGE और MERGE बीच सूक्ष्मताओं और UPSERT अंतरों को यहां और यहां (हम अपनी वेबसाइट पर पोस्टग्रेक्यूएल के संग्रहीत पत्राचार को संग्रहीत करते हैं) को अलग करते हैं।

साइमन ने विरोध किया। वह हाल के इतिहास की अपील करता है। जैसे, सेक्शनिंग के बारे में उन्होंने यह भी कहा "एक नया वाक्यविन्यास, इससे ज्यादा कुछ नहीं।" लेकिन यह एक बहुत ही उपयोगी चीज निकला। लेकिन मैं तुरंत सब कुछ महसूस करने का प्रस्ताव नहीं करता जो कि MERGE में है। हम विभाजन के साथ भी ऐसा ही करेंगे - हम विकास को चरणों में विभाजित करते हैं।

और एक और तर्क, मेरी राय में बहुत आश्वस्त करने वाला है: अच्छा। लेकिन चलो चुनते हैं। मैं एक व्यावहारिक विकल्प सुझाता हूं। 10 साल जल्द ही MERGE को विकसित करने के पहले गंभीर प्रयास से आएंगे । क्या यह सही समाधान के 10 वर्षों के लिए प्रतीक्षा करने के बजाय, कुछ करना शुरू करने, कुछ उपयोगी समाधान प्राप्त करने का समय नहीं है? यह मानते हुए कि यह सब मौजूद है।

अंत में, पैच समुदाय में आता है। किस तारीख को? कृपया कल्पना कीजिए। नहीं, उन्होंने अनुमान नहीं लगाया: साइमन 30 दिसंबर, 2017 को उन्हें भेजता है। और यह बताता है कि यह एक WIP पैच है, अर्थात वर्क इन प्रोग्रेस - वर्क इन पैच।

साइमन, जनवरी:
पैच बिना किसी विशेष बग के पूरा हो गया है। कोड प्लस परीक्षणों और प्रलेखन की 1200 लाइनें । मैं उसे इस कमिट करने जा रहा हूं, और हम आरएलएस (रो लेवल सिक्योरिटी - रिकॉर्डिंग स्तर पर सुरक्षा) और विभाजन समर्थन को बाद में पूरा करेंगे।

समितियों की जाति

यहां हमें अलग से एक कदम उठाना होगा और समुदाय में आयुक्त की भूमिका को समझाना होगा। आयुक्त के कार्य, अर्थात्, जो अगले संस्करण में पैच को स्वीकार करने के लिए सशक्त है, ऐतिहासिक रूप से बदल गया है। एक बार जब कुछ डेवलपर्स थे, तो प्रतिबद्ध होने का अधिकार उदारता से वितरित किया गया था। उदाहरण के लिए, प्रसिद्ध (एक पूरी तरह से अलग क्षेत्र में) जूलियन असांजे ने केवल छह पैच के लेखक होने के नाते कमांडर की उपाधि प्राप्त की। अब कमिश्नर बनना आसान नहीं है, एक दर्जन लोगों की सूची में कोई बदलाव नहीं हुआ है। बॉयस मोम्दजान (एंटरटीडीडीबी) में 13,363 कमिट्स हैं, टॉम लेन (टॉम लेन, कुरकुरे डेटा ) 13127, रॉबर्ट हास ( एंटरप्राइजबीडी ) - 2074। वैसे, रूस से एकमात्र कमेंट फेडर सिगेव ( पोस्टग्रेज प्रोफेशनल ) अपने 383 कमिट्स के साथ करता है। । साइमन रिग्स स्वयं के पास 449 हैं। मैं दोहराता हूं: वह, एक आयुक्त के रूप में, उनके और उनके कर्मचारियों को पैच लेने और प्रतिबद्ध करने के लिए पर्याप्त अधिकार है। एक और बात यह है कि यह शायद ही ऐसा करने योग्य है, अन्य प्रमुख लुमिनेरी-समितियों की राय की स्पष्ट रूप से उपेक्षा। वे एक आयुक्त की स्थिति से भी वंचित कर सकते हैं, लेकिन कम से कम वे पैच बैक को revert कर देंगे।

लड़ाई में फ्रैक्चर

बेशक, "निराशाजनक" पैच में, सामान्य रूप से, जल्दबाजी में, उन्हें नई त्रुटियां मिलती हैं। जवाब में नए संस्करण रोल।

जनवरी के अंत में, एक नया चरित्र दिखाई देता है: 2ndQuadrant Pavan का विकासक (उसका नाम हर किसी के पास है; पूरी तरह से Pavan Deolasee)। अब समुदाय एक महामारी के साथ काम कर रहा है: पवन नए संस्करण भेजता है और आलोचना के लिए धन्यवाद करता है, और साइमन एक उल्लेखनीय विपणन दबाव के साथ उन्हें तोड़ता है।

हास: मुझे नहीं लगता कि यह हर जगह काम करने वाली सुविधाओं के बहिष्कार पर एकतरफा निर्णय लेने के लायक है। यदि हम सहमत हैं कि इस पैच में कुछ विशेषताएं शामिल नहीं होंगी - तो यह एक बात है। और यह पूरी तरह से अलग है कि इस अवसर पर टिप्पणियों में सभी ने असहमति व्यक्त की। और हमने वास्तव में उन कारणों को नहीं सुना है कि इन सुविधाओं को बाहर क्यों रखा जाना चाहिए।

तर्क को इस प्रकार प्रस्तुत किया गया था:

• एक प्राथमिकता, गंभीर समस्याएं हैं क्योंकि वे "कैवेलरी हमले की शैली" के घटनाक्रम में नहीं हो सकते हैं।
• संस्करण 10-11 में नए विभाजन जैसे महत्वपूर्ण सुविधाओं के लिए समर्थन, सीटीई (कॉमन टेबल एक्सप्रेशन = प्रश्नों के साथ) या आरएलएस (रो लेवल सिक्योरिटी) पैच को वर्तमान संस्करण में स्वीकार किए जाने के बाद भी पूरा किया जा सकता है, लेकिन केवल तभी जब प्रस्तावित वास्तुकला शीर्ष पर निर्माण के लिए उपयुक्त हो। उसकी वांछित कार्यक्षमता।

दूसरा पीटर गीगन इसे तैयार करता है:
आमतौर पर मैं विभिन्न कार्यक्षमता के समर्थन पर ध्यान देता हूं , क्योंकि अगर यह है, तो यह सामान्य विश्वास को मजबूत करता है कि डिजाइन को वैसा ही बनाया जाए जैसा कि उसे चाहिए । और अगर इस तरह की समस्याएं अभिव्यक्तियों [अर्थात, CTE ] के समर्थन के कारण होती हैं, तो मुझे यह विचार मिलता है कि अंतर्निहित वास्तुकला ऐसी है कि यह यहां और वहां समस्याओं का कारण होगा।

इस बीच, घंटे X (अंतिम कमेटीफेस्ट) आ रहा है, और MERGE पर बादल जमा हो रहे हैं। ऐसा नहीं है कि संस्थापक पिता ने विशेष रूप से साइमन और फिर पावन द्वारा बनाई गई पेटिंग्स की वास्तुकला में गंभीर समस्याओं की तलाश की। मुझे समस्याओं की तलाश नहीं करनी थी, उन्होंने स्वेच्छा से खुद को खोला।

संप्रदाय निकट है

कथानक में तेजी आ रही है। अपने उपक्रम के प्रति अन्य समितियों के ठंडे रवैये के बावजूद, 2 अप्रैल को, साइमन ने एसक्यूएल: 2016 पैच के बाद कमान का फैसला किया, फाइल्स को जोड़ता है, डीपेज़ (ह्यूबर्ट लुबाचेवस्की) अपने ब्लॉग पर इसकी घोषणा करता है, लेकिन उसी दिन साइमन सब कुछ वापस कर देता है क्योंकि त्रुटियों।

अगले दिन, समर्थन के WITH जोड़कर फिर से प्रतिबद्ध करें।

जवाब में, आरोप वास्तव में गंभीर हैं। एंड्रेस फ्रायंड ( एंटरप्राइजडीबी ) लिखते हैं:
पार्सर और निष्पादनकर्ता में MERGE के लिए वास्तुकला ने मुझे मज़बूती से प्रभावित नहीं किया। पार्सिंग विश्लेषण के दौरान छिपे हुए जोड़ बनाना वास्तव में एक बुरा विचार है। निष्पादक की यह संरचना पूरी तरह से बदलनी चाहिए।

टॉम लेन:
पार्सिंग ट्री का डिज़ाइन कमजोर है।



आप InsertStmt फ़ंक्शन को InsertStmt करते हैं, वह जारी रखता है, यह INSERT बिल्कुल नहीं करता है, लेकिन इसमें यादृच्छिक रूप से मूल के समान फ़ील्ड होते हैं। और सभी नहीं, लेकिन कुछ। यह बुरा है, इससे भ्रम पैदा होता है।

आइए फेडर सिगाएव की टिप्पणियों को जोड़ें:
पार्सर में, MERGE संबंधित INSERT नोड्स दिखाई दिए, जो अतिरिक्त क्षेत्रों के एक समूह के साथ लटकाए गए थे। यदि आप ANALIZE में निष्पादन योजना को ANALIZE , तो आप तुरंत यह नहीं समझ पाएंगे कि आप नियमित INSERT साथ काम कर रहे हैं या MERGE साथ: समझने के लिए, आपको अतिरिक्त फ़ील्ड देखने की आवश्यकता है।


साइमन, शांति से: ठीक है, हम इसे बदल देंगे और कल एक नई फ़ाइल भेजेंगे ।
Haas: मैं पीटर के साथ सहमत हूँ। वास्तुकला का विकल्प असफल है।

साइमन हार नहीं मानता। 6 अप्रैल, टॉम लेन की आलोचना के जवाब में, पार्सर में संशोधन के रूप में एक नया पैच करता है।

बातचीत और समर्पण

ब्रूस मोम्जन 6 अप्रैल :
मैं यह नोट करना चाहता हूं कि लोगों ने आपको तत्काल कुछ ठीक करने के लिए कड़ी मेहनत करने के लिए नहीं कहा। उन्होंने आपको पैच वापस लेने के लिए कहा। आप निश्चित रूप से, कड़ी मेहनत कर सकते हैं, उम्मीद करते हैं कि वे अपने दिमाग को बदल देंगे, लेकिन - फिर से - उन्होंने उस बारे में आपसे नहीं पूछा।

साइमन: अगर टॉम [लेन] और एंड्रेस [फ्रायंड] शेष कुछ दिनों के लिए अभी भी महसूस करते हैं कि उनके डर को दूर नहीं किया गया है, तो मुझे आगे की हलचल के बिना पैच को वापस करने में खुशी होगी ।

टॉम लेन: मैं अभी भी पैच के लिए वापस लुढ़का हुआ हूं। यहां तक ​​कि अगर वह अब परिपूर्ण थे, तो अब लोगों के पास इस बारे में आश्वस्त होने का समय नहीं है - अन्य जरूरी मामलों के गले के लिए।

वह सब है।

साइमन ने कहा ठीक है, और MERGE पर लड़ाई खत्म हो MERGE थी। सभी पैच को वापस पंप किया गया है, इस विषय को "लेखक के समापन की प्रतीक्षा" की स्थिति के साथ अगले कमेट में ले जाया गया है। शो में शामिल प्रतिभागियों ने शांति बनाए रखी।


हालांकि, हाल के हफ्तों के पत्राचार को देखते हुए, कुछ तनाव बना हुआ है।

नैतिकता का वादा किया

• सौभाग्य से, PostgreSQL समुदाय में अपरिपक्व समाधानों के प्रयासों के लिए (लगभग) संघर्ष-मुक्त स्क्रीनिंग के लिए प्राकृतिक और औपचारिक तंत्र हैं। भले ही वे कंपनी के प्रमुख के रैंक में सम्मानित डेवलपर्स द्वारा पंच किए गए हों, जिनके पोस्टग्रेक्यूएल के विकास में योगदान बहुत बड़ा है। और जिन ग्राहकों में कार्यक्षमता की कमी है वे निवेश करने पर जोर दे रहे हैं।
• दुर्भाग्य से, समुदाय अक्सर स्टालों। असंदिग्ध रूप से प्रासंगिक विकास को अपनाने में यह निष्क्रिय है। कभी-कभी तर्कहीन पूर्णतावाद शामिल होता है। पोस्टग्रैज प्रोफेशनल का अनुभव, जहां मैं काम करता हूं, इसकी पुष्टि करता है। हमने 3 वर्षों के लिए INCLUDE सूचकांकों के एक बड़े और महत्वपूर्ण पैच को छिद्रित किया। JSON / JSONB के साथ काम करने के लिए पैच की एक उपयोगी श्रृंखला अभी भी इंतजार कर रही है। अभिव्यक्ति "समुदाय के लिए अपना विकास दें" वास्तव में देने का मतलब नहीं है , लेकिन छिद्रण : अतिथि को खुली बाहों से बधाई दी जाती है और संगरोध के लिए रवाना किया जाता है।

पुनश्च: लेखक से अस्वीकरण : हम सिर्फ सामुदायिक जीवन का एक टुकड़ा दिखाना चाहते थे। सभी नाम मिलान यादृच्छिक हैं :)
PPS: समुराई नतालिया लेवशिना ।