शंकास्पद प्रकारहरू

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

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

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

यस्तो देखिन्छ कि संख्यात्मक प्रकारहरू व्यवहार मा आश्चर्य को मामला मा कम से कम समस्याग्रस्त छन्। तर जस्तोसुकै भए पनि । त्यसैले तिनीहरूसँग सुरु गरौं। तर…

कसरी गणना गर्ने बिर्सनुभयो

SELECT 0.1::real = 0.1

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

के भयो? समस्या यो हो कि पोस्टग्रेएसक्यूएलले टाइप नगरिएको स्थिर ०.१ लाई डबल परिशुद्धतामा रूपान्तरण गर्दछ र यसलाई वास्तविक प्रकारको ०.१ सँग तुलना गर्ने प्रयास गर्दछ। र यी पूर्णतया फरक अर्थहरू छन्! विचार मेसिन मेमोरीमा वास्तविक संख्याहरू प्रतिनिधित्व गर्ने हो। ०.१ लाई सीमित बाइनरी अंशको रूपमा प्रतिनिधित्व गर्न सकिँदैन (यो बाइनरीमा ०.० (००११) हुनेछ), फरक बिट गहिराइ भएका संख्याहरू फरक हुनेछन्, त्यसैले तिनीहरू बराबर छैनन् भन्ने परिणाम। सामान्यतया भन्नुपर्दा, यो छुट्टै लेखको लागि विषय हो; म यहाँ थप विस्तारमा लेख्ने छैन।

त्रुटि कहाँबाट आउँछ?

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) पनि लेख्न सक्नुहुन्छ, जुन बराबर हुनेछ। तर नामहरूमा धेरै शब्दहरू समावेश भएका प्रकारहरूको लागि होइन! तसर्थ, यदि तपाइँ कार्यात्मक रूप मा डबल सटीक प्रकार को लागी एक संख्यात्मक मान कास्ट गर्न चाहनुहुन्छ भने, यस प्रकार को उपनाम प्रयोग गर्नुहोस् float8, त्यो हो, SELECT float8(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 trifles मा समय बर्बाद गर्न मन पराउँदैन। स्मॉलइन्टमा आधारित यी अनुक्रमहरू के हुन्? 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 बाइटहरू लिन्छ, परिणामलाई बाइट प्रकारमा रूपान्तरण गरेर प्रमाणित हुन्छ। र "char" प्रकारले यो युनिकोड प्रतिनिधित्वको पहिलो बाइट मात्र लिन्छ। त्यसोभए यो प्रकार किन आवश्यक छ? 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

दिइएको उदाहरण हेरौं। मैले विशेष रूपमा सबै नतिजाहरूलाई बाइट प्रकारमा रूपान्तरण गरें ताकि त्यहाँ के थियो त्यो स्पष्ट रूपमा देखिन्थ्यो। varchar(6) मा कास्ट गरिसकेपछि पछि लाग्ने ठाउँहरू कहाँ छन्? कागजातले संक्षिप्त रूपमा बताउँछ: "अर्को क्यारेक्टर प्रकारमा क्यारेक्टरको मान कास्ट गर्दा, ट्रेलिङ व्हाइटस्पेस खारेज गरिन्छ।" यो असन्तुष्टि सम्झनुपर्छ। र नोट गर्नुहोस् कि यदि उद्धृत स्ट्रिङ स्थिरता सिधै टाइप varchar(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 datestyle आदेशको साथ datestyle प्यारामिटर विश्लेषण गर्नुहोस्), किनकि यस विषयमा अस्पष्टताहरू धेरै महँगो हुन सक्छ।

तपाईंले यो कहाँबाट पाउनुभयो?

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

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

उसलाई के गल्ती छ?

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

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

के भयो? तथ्य यो हो कि मिति प्रकारमा timestamptz प्रकार कास्ट गर्न, TimeZone प्रणाली प्यारामिटरको मान प्रयोग गरिन्छ, जसले प्रकार रूपान्तरण प्रकार्यलाई अनुकूलन प्यारामिटरमा निर्भर गर्दछ, अर्थात्। अस्थिर। यस्तो प्रकार्यहरू अनुक्रमणिकामा अनुमति छैन। यस अवस्थामा, तपाईंले स्पष्ट रूपमा संकेत गर्नुपर्छ कि कुन समय क्षेत्रमा प्रकार कास्ट गरिन्छ।

जतिबेला अहिले पनि छैन

हामी अहिले () हालको मिति/समय फर्काउने बानी परेका छौं, समय क्षेत्रलाई ध्यानमा राख्दै। तर निम्न प्रश्नहरू हेर्नुहोस्:

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(); वास्तवमा, हालको होइन... यदि तपाईं इमानदार वर्तमान समय प्राप्त गर्न चाहनुहुन्छ भने, तपाईंले clock_timestamp() प्रकार्य प्रयोग गर्न आवश्यक छ।

फाइल नम्बर पाँच। बिट

अलिकति अनौठो

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