संशयास्पद प्रकार

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

PostgreSQL मधील डेटा टायपिंग, त्याच्या सर्व तर्कांसाठी, कधीकधी खूप विचित्र आश्चर्य सादर करते. या लेखात आम्ही त्यांच्या काही विचित्र गोष्टी स्पष्ट करण्याचा प्रयत्न करू, त्यांच्या विचित्र वागण्याचे कारण समजून घेऊ आणि दैनंदिन व्यवहारात समस्यांना कसे सामोरे जाऊ नये हे समजून घेऊ. सत्य सांगण्यासाठी, मी हा लेख माझ्यासाठी एक प्रकारचा संदर्भ पुस्तक म्हणून संकलित केला आहे, एक संदर्भ पुस्तक ज्याचा संदर्भ विवादास्पद प्रकरणांमध्ये सहजपणे करता येईल. त्यामुळे, संशयास्पद प्रकारांमधुन नवीन आश्चर्याचा शोध लागल्याने ते पुन्हा भरले जाईल. तर, चला, अथक डेटाबेस ट्रॅकर्स!

डॉजियर नंबर एक. वास्तविक/दुहेरी अचूकता/संख्यात्मक/पैसा

असे दिसते की संख्यात्मक प्रकार वर्तनातील आश्चर्यांच्या बाबतीत सर्वात कमी समस्याप्रधान आहेत. पण ते कसेही असो. तर त्यांच्यापासून सुरुवात करूया. त्यामुळे…

कसे मोजायचे ते विसरलो

SELECT 0.1::real = 0.1

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

काय झला? समस्या अशी आहे की पोस्टग्रेएसक्यूएल टाइप न केलेल्या स्थिरांक 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

बर्‍याच लोकांना माहित आहे की पोस्टग्रेएसक्यूएल टाइप कास्टिंगसाठी कार्यात्मक नोटेशनला अनुमती देते. म्हणजेच, तुम्ही फक्त 1::int नाही तर int(1) देखील लिहू शकता, जे समतुल्य असेल. परंतु अशा प्रकारांसाठी नाही ज्यांच्या नावांमध्ये अनेक शब्द आहेत! म्हणून, जर तुम्हाला फंक्शनल फॉर्ममध्ये दुप्पट अचूक प्रकारासाठी अंकीय मूल्य कास्ट करायचे असेल, तर या प्रकारच्या फ्लोट8 चे उपनाव वापरा, म्हणजे 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 ला क्षुल्लक गोष्टींवर वेळ वाया घालवायला आवडत नाही. स्मॉलइंटवर आधारित हे अनुक्रम काय आहेत? int, कमी नाही! म्हणून, वरील क्वेरी कार्यान्वित करण्याचा प्रयत्न करताना, डेटाबेस इतर काही पूर्णांक प्रकारात स्मॉलइंट कास्ट करण्याचा प्रयत्न करतो आणि असे अनेक कास्ट असू शकतात हे पाहतो. कोणती कास्ट निवडायची? ती हे ठरवू शकत नाही, आणि म्हणून त्रुटीसह क्रॅश होते.

फाईल क्रमांक दोन. "char"/char/varchar/text

वर्ण प्रकारांमध्ये अनेक विचित्रता देखील आहेत. त्यांनाही जाणून घेऊया.

या कोणत्या प्रकारच्या युक्त्या आहेत?

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

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

हा कोणत्या प्रकारचा "चार" आहे, हा कोणता विदूषक आहे? आम्हाला त्यांची गरज नाही... कारण ते कोट्समध्ये असले तरीही ते सामान्य वर्ण असल्याचे भासवते. आणि हे रेग्युलर char पेक्षा वेगळे आहे, जे कोट्स शिवाय असते, ज्यामध्ये ते स्ट्रिंग रिप्रेझेंटेशनचा फक्त पहिला बाइट आउटपुट करते, तर सामान्य char प्रथम कॅरेक्टर आउटपुट करते. आमच्या बाबतीत, पहिले अक्षर पी हे अक्षर आहे, जे युनिकोड प्रस्तुतीकरणात 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

डेटाबेस स्पष्टपणे निर्दिष्ट वेळ का समजू शकत नाही? कारण टाइम झोनमध्ये संक्षेप नाही, परंतु पूर्ण नाव आहे, जे केवळ तारखेच्या संदर्भात अर्थ देते, कारण ते टाइम झोन बदलांचा इतिहास लक्षात घेते आणि ते तारखेशिवाय कार्य करत नाही. आणि टाइम लाइनचे शब्दच प्रश्न निर्माण करतात - प्रोग्रामरचा खरोखर काय अर्थ होता? म्हणून, येथे सर्व काही तर्कसंगत आहे, जर आपण ते पहाल.

त्याचे काय बिघडले आहे?

परिस्थितीची कल्पना करा. तुमच्‍या टेबलमध्‍ये टाईमस्‍टॅम्‍ट्झ टाईप असलेले फील्‍ड आहे. तुम्हाला ते अनुक्रमित करायचे आहे. परंतु आपण समजता की या फील्डवर निर्देशांक तयार करणे नेहमीच त्याच्या उच्च निवडकतेमुळे न्याय्य नसते (या प्रकारची जवळजवळ सर्व मूल्ये अद्वितीय असतील). त्यामुळे तुम्ही प्रकाराला तारखेला कास्ट करून निर्देशांकाची निवडकता कमी करण्याचे ठरवता. आणि तुम्हाला एक आश्चर्य मिळेल:

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

काय झला? वस्तुस्थिती अशी आहे की तारखेच्या प्रकारावर टाइमस्टॅम्प्ट्झ प्रकार कास्ट करण्यासाठी, टाइमझोन सिस्टम पॅरामीटरचे मूल्य वापरले जाते, जे प्रकार रूपांतरण कार्य कस्टम पॅरामीटरवर अवलंबून असते, उदा. अस्थिर निर्देशांकात अशा कार्यांना परवानगी नाही. या प्रकरणात, कोणत्या टाइम झोनमध्ये प्रकार कास्ट केला जातो हे तुम्ही स्पष्टपणे सूचित केले पाहिजे.

जेव्हा आता नाही तर आता अजिबात नाही

आम्हाला टाइम झोन लक्षात घेऊन, वर्तमान तारीख/वेळ परत करण्याची सवय आहे. परंतु खालील प्रश्न पहा:

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