संदिग्ध प्रकार

उनकी शक्ल-सूरत में कुछ भी संदेहास्पद नहीं है. इसके अलावा, वे आपको अच्छी तरह से और लंबे समय से परिचित भी लगते हैं। लेकिन यह केवल तब तक है जब तक आप उनकी जाँच नहीं करते। यहीं पर वे अपना कपटी स्वभाव दिखाते हैं, आपकी अपेक्षा से बिल्कुल अलग तरीके से काम करते हैं। और कभी-कभी वे कुछ ऐसा करते हैं जिससे आपके रोंगटे खड़े हो जाते हैं - उदाहरण के लिए, वे उन्हें सौंपा गया गुप्त डेटा खो देते हैं। जब आप उनका सामना करते हैं, तो वे दावा करते हैं कि वे एक-दूसरे को नहीं जानते, हालांकि छाया में वे एक ही आड़ में कड़ी मेहनत करते हैं। आख़िरकार उन्हें साफ़ पानी में लाने का समय आ गया है। आइए हम भी इन संदिग्ध प्रकारों से निपटें।

PostgreSQL में डेटा टाइपिंग, अपने सभी तर्कों के बावजूद, कभी-कभी बहुत अजीब आश्चर्य पेश करती है। इस लेख में हम उनकी कुछ विचित्रताओं को स्पष्ट करने का प्रयास करेंगे, उनके अजीब व्यवहार का कारण समझेंगे और समझेंगे कि रोजमर्रा के व्यवहार में समस्याओं से कैसे बचा जाए। सच कहूँ तो, मैंने इस लेख को अपने लिए एक प्रकार की संदर्भ पुस्तक के रूप में भी संकलित किया है, एक ऐसी संदर्भ पुस्तक जिसे विवादास्पद मामलों में आसानी से संदर्भित किया जा सकता है। इसलिए, संदिग्ध प्रकारों से नए आश्चर्य की खोज होने पर इसकी भरपाई की जाएगी। तो चलिए, हे अथक डेटाबेस ट्रैकर्स!

डोजियर नंबर एक. वास्तविक/दोहरी परिशुद्धता/संख्यात्मक/पैसा

ऐसा प्रतीत होता है कि व्यवहार में आश्चर्य के मामले में संख्यात्मक प्रकार सबसे कम समस्याग्रस्त हैं। लेकिन चाहे वो कैसा भी हो. तो चलिए उनसे शुरू करते हैं। इसलिए…

गिनना भूल गया

SELECT 0.1::real = 0.1

?column?
boolean
---------
f

क्या बात क्या बात? समस्या यह है कि PostgreSQL अलिखित स्थिरांक 0.1 को दोहरी परिशुद्धता में परिवर्तित करता है और वास्तविक प्रकार के 0.1 के साथ इसकी तुलना करने का प्रयास करता है। और ये बिल्कुल अलग अर्थ हैं! विचार मशीन मेमोरी में वास्तविक संख्याओं का प्रतिनिधित्व करना है। चूँकि 0.1 को एक परिमित बाइनरी अंश के रूप में प्रस्तुत नहीं किया जा सकता है (बाइनरी में यह 0.0(0011) होगा), अलग-अलग बिट गहराई वाली संख्याएँ अलग-अलग होंगी, इसलिए परिणाम यह होगा कि वे समान नहीं हैं। सामान्यतया, यह एक अलग लेख का विषय है; मैं यहां अधिक विस्तार से नहीं लिखूंगा।

त्रुटि कहां से आती है?

SELECT double precision(1)

ERROR:  syntax error at or near "("
LINE 1: SELECT double precision(1)
                               ^
********** Ошибка **********
ERROR: syntax error at or near "("
SQL-состояние: 42601
Символ: 24

बहुत से लोग जानते हैं कि PostgreSQL टाइप कास्टिंग के लिए कार्यात्मक नोटेशन की अनुमति देता है। यानी आप न केवल 1::int, बल्कि int(1) भी लिख सकते हैं, जो समतुल्य होगा। लेकिन उन प्रकारों के लिए नहीं जिनके नाम में कई शब्द होते हैं! इसलिए, यदि आप कार्यात्मक रूप में दोहरे परिशुद्धता प्रकार के लिए एक संख्यात्मक मान डालना चाहते हैं, तो इस प्रकार के फ्लोट 8 के उपनाम का उपयोग करें, अर्थात, सेलेक्ट फ्लोट 8 (1)।

अनंत से बड़ा क्या है?

SELECT 'Infinity'::double precision < 'NaN'::double precision

?column?
boolean
---------
t

देखो यह कैसा है! यह पता चला कि अनंत से भी बड़ा कुछ है, और यह NaN है! उसी समय, PostgreSQL दस्तावेज़ हमें ईमानदार आँखों से देखता है और दावा करता है कि NaN स्पष्ट रूप से किसी भी अन्य संख्या से अधिक है, और इसलिए, अनंत है। -NaN के लिए विपरीत भी सत्य है। नमस्कार, गणित प्रेमियों! लेकिन हमें याद रखना चाहिए कि यह सब वास्तविक संख्याओं के संदर्भ में संचालित होता है।

आँख गोल होना

SELECT round('2.5'::double precision)
     , round('2.5'::numeric)

      round      |  round
double precision | numeric
-----------------+---------
2                | 3

बेस से एक और अप्रत्याशित शुभकामना। फिर से, याद रखें कि दोहरे परिशुद्धता और संख्यात्मक प्रकारों के अलग-अलग गोलाई प्रभाव होते हैं। संख्यात्मक के लिए - सामान्य एक, जब 0,5 को पूर्णांकित किया जाता है, और दोहरी परिशुद्धता के लिए - 0,5 को निकटतम सम पूर्णांक की ओर पूर्णांकित किया जाता है।

पैसा कुछ खास चीज है

SELECT '10'::money::float8

ERROR:  cannot cast type money to double precision
LINE 1: SELECT '10'::money::float8
                          ^
********** Ошибка **********
ERROR: cannot cast type money to double precision
SQL-состояние: 42846
Символ: 19

PostgreSQL के अनुसार, पैसा कोई वास्तविक संख्या नहीं है। कुछ व्यक्तियों के अनुसार भी. हमें यह याद रखने की आवश्यकता है कि धन प्रकार को केवल संख्यात्मक प्रकार में डालना संभव है, जैसे केवल संख्यात्मक प्रकार को धन प्रकार में डालना संभव है। लेकिन अब आप इसके साथ अपनी दिल की इच्छानुसार खेल सकते हैं। लेकिन यह वही पैसा नहीं होगा.

स्मालिंट और अनुक्रम पीढ़ी

SELECT *
  FROM generate_series(1::smallint, 5::smallint, 1::smallint)

ERROR:  function generate_series(smallint, smallint, smallint) is not unique
LINE 2:   FROM generate_series(1::smallint, 5::smallint, 1::smallint...
               ^
HINT:  Could not choose a best candidate function. You might need to add explicit type casts.
********** Ошибка **********
ERROR: function generate_series(smallint, smallint, smallint) is not unique
SQL-состояние: 42725
Подсказка: Could not choose a best candidate function. You might need to add explicit type casts.
Символ: 18

PostgreSQL को छोटी-छोटी बातों पर समय बर्बाद करना पसंद नहीं है। स्मालिंट पर आधारित ये क्रम क्या हैं? int, कम नहीं! इसलिए, उपरोक्त क्वेरी को निष्पादित करने का प्रयास करते समय, डेटाबेस स्मॉलिंट को किसी अन्य पूर्णांक प्रकार में डालने का प्रयास करता है, और देखता है कि ऐसे कई कास्ट हो सकते हैं। कौन सी कास्ट चुनें? वह यह तय नहीं कर सकती, और इसलिए एक त्रुटि के साथ क्रैश हो जाती है।

फाइल नंबर दो. "char"/char/varchar/text

चरित्र प्रकारों में भी अनेक विचित्रताएँ विद्यमान हैं। आइए इन्हें भी जान लीजिए.

ये कैसी चालें हैं?

SELECT 'ПЕТЯ'::"char"
     , 'ПЕТЯ'::"char"::bytea
     , 'ПЕТЯ'::char
     , 'ПЕТЯ'::char::bytea

 char  | bytea |    bpchar    | bytea
"char" | bytea | character(1) | bytea
-------+-------+--------------+--------
 ╨     | xd0  | П            | xd09f

यह किस प्रकार का "चार" है, यह किस प्रकार का विदूषक है? हमें उनकी आवश्यकता नहीं है... क्योंकि यह एक सामान्य अक्षर होने का दिखावा करता है, भले ही यह उद्धरण चिह्नों में हो। और यह एक नियमित चार से भिन्न होता है, जो बिना उद्धरण के होता है, इसमें यह स्ट्रिंग प्रतिनिधित्व के केवल पहले बाइट को आउटपुट करता है, जबकि एक सामान्य चार पहले चरित्र को आउटपुट करता है। हमारे मामले में, पहला अक्षर P अक्षर है, जो यूनिकोड प्रतिनिधित्व में 2 बाइट्स लेता है, जैसा कि परिणाम को बाइट प्रकार में परिवर्तित करके प्रमाणित किया गया है। और "चार" प्रकार इस यूनिकोड प्रतिनिधित्व का केवल पहला बाइट लेता है। फिर इस प्रकार की आवश्यकता क्यों है? PostgreSQL दस्तावेज़ कहता है कि यह विशेष आवश्यकताओं के लिए उपयोग किया जाने वाला एक विशेष प्रकार है। इसलिए हमें इसकी आवश्यकता पड़ने की संभावना नहीं है। लेकिन उसकी आंखों में देखें और जब आप उससे उसके खास व्यवहार के साथ मिलेंगे तो गलती नहीं करेंगे।

अतिरिक्त स्थान. आँखों से ओझल वस्तु को हम भूल जाते हैं

SELECT 'abc   '::char(6)::bytea
     , 'abc   '::char(6)::varchar(6)::bytea
     , 'abc   '::varchar(6)::bytea

     bytea     |   bytea  |     bytea
     bytea     |   bytea  |     bytea
---------------+----------+----------------
x616263202020 | x616263 | x616263202020

दिए गए उदाहरण पर एक नजर डालें. मैंने विशेष रूप से सभी परिणामों को बाइट प्रकार में परिवर्तित कर दिया, ताकि यह स्पष्ट रूप से दिखाई दे कि वहां क्या था। वर्चर(6) में कास्टिंग के बाद पिछली जगहें कहां हैं? दस्तावेज़ में संक्षेप में कहा गया है: "जब चरित्र के मान को किसी अन्य चरित्र प्रकार में डाला जाता है, तो अनुगामी रिक्त स्थान को छोड़ दिया जाता है।" इस नापसंदगी को याद रखना चाहिए. और ध्यान दें कि यदि उद्धृत स्ट्रिंग स्थिरांक को सीधे वर्चर (6) टाइप करने के लिए डाला जाता है, तो अनुगामी रिक्त स्थान संरक्षित होते हैं। चमत्कार ऐसे ही होते हैं.

फ़ाइल संख्या तीन. json/jsonb

JSON एक अलग संरचना है जो अपना जीवन जीती है। इसलिए, इसकी इकाइयाँ और PostgreSQL की इकाइयाँ थोड़ी भिन्न हैं। यहाँ उदाहरण हैं.

जॉनसन एंड जॉनसन. फर्क महसूस करो

SELECT 'null'::jsonb IS NULL

?column?
boolean
---------
f

बात यह है कि JSON की अपनी शून्य इकाई है, जो PostgreSQL में NULL का एनालॉग नहीं है। उसी समय, JSON ऑब्जेक्ट का मान NULL हो सकता है, इसलिए अभिव्यक्ति SELECT null::jsonb IS NULL (सिंगल कोट्स की अनुपस्थिति पर ध्यान दें) इस बार सही हो जाएगी।

एक अक्षर सब कुछ बदल देता है

SELECT '{"1": [1, 2, 3], "2": [4, 5, 6], "1": [7, 8, 9]}'::json

                     json
                     json
------------------------------------------------
{"1": [1, 2, 3], "2": [4, 5, 6], "1": [7, 8, 9]}

---

SELECT '{"1": [1, 2, 3], "2": [4, 5, 6], "1": [7, 8, 9]}'::jsonb

             jsonb
             jsonb
--------------------------------
{"1": [7, 8, 9], "2": [4, 5, 6]}

बात यह है कि json और jsonb पूरी तरह से अलग संरचनाएँ हैं। json में, ऑब्जेक्ट को वैसे ही संग्रहीत किया जाता है, और jsonb में यह पहले से ही एक पार्स किए गए, अनुक्रमित संरचना के रूप में संग्रहीत किया जाता है। इसीलिए दूसरे मामले में, कुंजी 1 द्वारा ऑब्जेक्ट का मान [1, 2, 3] से बदलकर [7, 8, 9] कर दिया गया, जो उसी कुंजी के साथ सबसे अंत में संरचना में आया।

अपने चेहरे से पानी न पियें

SELECT '{"reading": 1.230e-5}'::jsonb
     , '{"reading": 1.230e-5}'::json

          jsonb         |         json
          jsonb         |         json
------------------------+----------------------
{"reading": 0.00001230} | {"reading": 1.230e-5}

PostgreSQL अपने JSONB कार्यान्वयन में वास्तविक संख्याओं के स्वरूपण को बदलता है, उन्हें शास्त्रीय रूप में लाता है। JSON प्रकार के लिए ऐसा नहीं होता है. थोड़ा अजीब है, लेकिन वह सही है।

फ़ाइल संख्या चार. दिनांक/समय/टाइमस्टैम्प

दिनांक/समय प्रकार के साथ कुछ विषमताएँ भी हैं। आइए उन पर नजर डालें. मैं तुरंत एक आरक्षण कर दूं कि यदि आप समय क्षेत्रों के साथ काम करने के सार को अच्छी तरह से समझते हैं तो व्यवहार की कुछ विशेषताएं स्पष्ट हो जाएंगी। लेकिन यह भी एक अलग लेख का विषय है.

मेरी समझ में नहीं आता तुम्हारा

SELECT '08-Jan-99'::date

ERROR:  date/time field value out of range: "08-Jan-99"
LINE 1: SELECT '08-Jan-99'::date
               ^
HINT:  Perhaps you need a different "datestyle" setting.
********** Ошибка **********
ERROR: date/time field value out of range: "08-Jan-99"
SQL-состояние: 22008
Подсказка: Perhaps you need a different "datestyle" setting.
Символ: 8

ऐसा लगेगा कि यहाँ क्या समझ से परे है? लेकिन डेटाबेस अभी भी यह नहीं समझ पाया है कि हमने यहां पहले स्थान पर क्या रखा है - वर्ष या दिन? और वह निर्णय लेती है कि यह 99 जनवरी 2008 है, जो उसके होश उड़ा देता है। आम तौर पर, पाठ प्रारूप में तिथियां प्रेषित करते समय, आपको बहुत सावधानी से जांचने की आवश्यकता होती है कि डेटाबेस ने उन्हें कितनी सही ढंग से पहचाना (विशेष रूप से, SHOW डेटस्टाइल कमांड के साथ डेटस्टाइल पैरामीटर का विश्लेषण करें), क्योंकि इस मामले में अस्पष्टता बहुत महंगी हो सकती है।

आपको यह कहां से मिला?

SELECT '04:05 Europe/Moscow'::time

ERROR:  invalid input syntax for type time: "04:05 Europe/Moscow"
LINE 1: SELECT '04:05 Europe/Moscow'::time
               ^
********** Ошибка **********
ERROR: invalid input syntax for type time: "04:05 Europe/Moscow"
SQL-состояние: 22007
Символ: 8

डेटाबेस स्पष्ट रूप से निर्दिष्ट समय को क्यों नहीं समझ सकता? क्योंकि समय क्षेत्र का कोई संक्षिप्त नाम नहीं है, बल्कि एक पूरा नाम है, जो केवल एक तारीख के संदर्भ में समझ में आता है, क्योंकि यह समय क्षेत्र परिवर्तनों के इतिहास को ध्यान में रखता है, और यह तारीख के बिना काम नहीं करता है। और समय रेखा की शब्दावली ही सवाल उठाती है - प्रोग्रामर का वास्तव में क्या मतलब था? इसलिए, यदि आप इसे देखें तो यहां सब कुछ तार्किक है।

उसको क्या हुआ है?

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

CREATE INDEX "iIdent-DateLastUpdate"
  ON public."Ident" USING btree
  (("DTLastUpdate"::date));

ERROR:  functions in index expression must be marked IMMUTABLE
********** Ошибка **********
ERROR: functions in index expression must be marked IMMUTABLE
SQL-состояние: 42P17

क्या बात क्या बात? तथ्य यह है कि टाइमस्टैम्पज़ प्रकार को दिनांक प्रकार में डालने के लिए, टाइमज़ोन सिस्टम पैरामीटर का मान उपयोग किया जाता है, जो प्रकार रूपांतरण फ़ंक्शन को कस्टम पैरामीटर पर निर्भर बनाता है, यानी। परिवर्तनशील। सूचकांक में ऐसे कार्यों की अनुमति नहीं है। इस मामले में, आपको स्पष्ट रूप से इंगित करना होगा कि टाइप कास्ट किस समय क्षेत्र में किया जाता है।

जब अभी है ही नहीं

हम समय क्षेत्र को ध्यान में रखते हुए, वर्तमान दिनांक/समय को now() लौटाने के आदी हैं। लेकिन निम्नलिखित प्रश्नों को देखें:

START TRANSACTION;
SELECT now();

            now
  timestamp with time zone
-----------------------------
2019-11-26 13:13:04.271419+03

...

SELECT now();

            now
  timestamp with time zone
-----------------------------
2019-11-26 13:13:04.271419+03

...

SELECT now();

            now
  timestamp with time zone
-----------------------------
2019-11-26 13:13:04.271419+03

COMMIT;

दिनांक/समय वही लौटाया जाता है, चाहे पिछले अनुरोध के बाद कितना भी समय बीत गया हो! क्या बात क्या बात? तथ्य यह है कि now() वर्तमान समय नहीं है, बल्कि वर्तमान लेनदेन का प्रारंभ समय है। इसलिए, यह लेनदेन के भीतर नहीं बदलता है। लेन-देन के दायरे से बाहर लॉन्च की गई कोई भी क्वेरी अंतर्निहित रूप से लेन-देन में लपेटी जाती है, यही कारण है कि हम यह ध्यान नहीं देते हैं कि एक साधारण SELECT now() द्वारा लौटाया गया समय; वास्तव में, वर्तमान समय नहीं... यदि आप एक ईमानदार वर्तमान समय प्राप्त करना चाहते हैं, तो आपको क्लॉक_टाइमस्टैम्प() फ़ंक्शन का उपयोग करने की आवश्यकता है।

फाइल नंबर पांच. अंश

थोड़ा अजीब है

SELECT '111'::bit(4)

 bit
bit(4)
------
1110

टाइप एक्सटेंशन के मामले में बिट्स को किस तरफ जोड़ा जाना चाहिए? ऐसा लगता है कि यह बायीं ओर है। लेकिन इस मामले पर आधार की ही अलग राय है. सावधान रहें: यदि टाइप कास्टिंग करते समय अंकों की संख्या मेल नहीं खाती है, तो आपको वह नहीं मिलेगा जो आप चाहते थे। यह बिट्स को दाईं ओर जोड़ने और बिट्स को ट्रिम करने दोनों पर लागू होता है। दाहिनी ओर भी...

फ़ाइल संख्या छह. सरणियों

यहां तक ​​कि NULL में भी गोली नहीं चली

SELECT ARRAY[1, 2] || NULL

?column?
integer[]
---------
{1,2}

जैसा कि सामान्य लोग SQL पर करते हैं, हम उम्मीद करते हैं कि इस अभिव्यक्ति का परिणाम NULL होगा। लेकिन वह वहां नहीं था. एक सरणी लौटा दी गई है. क्यों? क्योंकि इस मामले में आधार NULL को एक पूर्णांक सरणी में डालता है और स्पष्ट रूप से array_cat फ़ंक्शन को कॉल करता है। लेकिन यह अभी भी स्पष्ट नहीं है कि यह "एरे कैट" एरे को रीसेट क्यों नहीं करता है। इस व्यवहार को भी बस याद रखने की जरूरत है।

संक्षेप। बहुत सारी अजीब चीजें हैं. निःसंदेह, उनमें से अधिकांश इतने आलोचनात्मक नहीं हैं कि खुले तौर पर अनुचित व्यवहार के बारे में बात करें। और दूसरों को उपयोग में आसानी या कुछ स्थितियों में उनकी प्रयोज्यता की आवृत्ति द्वारा समझाया गया है। लेकिन साथ ही, कई आश्चर्य भी हैं। इसलिए आपको इनके बारे में जानना जरूरी है. यदि आपको किसी भी प्रकार के व्यवहार में कुछ और अजीब या असामान्य लगता है, तो टिप्पणियों में लिखें, मुझे उन पर उपलब्ध डोजियर में जोड़ने में खुशी होगी।

स्रोत: www.habr.com