সন্দেহজনক প্রকার

তাদের চেহারা নিয়ে সন্দেহজনক কিছু নেই। তদুপরি, তারা এমনকি আপনার কাছে ভাল এবং দীর্ঘ সময়ের জন্য পরিচিত বলে মনে হচ্ছে। কিন্তু আপনি তাদের চেক করা পর্যন্ত যে শুধুমাত্র. এখানেই তারা তাদের ছলনাময় প্রকৃতি দেখায়, আপনার প্রত্যাশার চেয়ে সম্পূর্ণ ভিন্নভাবে কাজ করে। এবং কখনও কখনও তারা এমন কিছু করে যা আপনার চুলকে শেষ করে দেয় - উদাহরণস্বরূপ, তারা তাদের উপর অর্পিত গোপন ডেটা হারায়। আপনি যখন তাদের মুখোমুখি হন, তারা দাবি করে যে তারা একে অপরকে চেনে না, যদিও ছায়ায় তারা একই হুডের নীচে কঠোর পরিশ্রম করে। অবশেষে তাদের পরিষ্কার জলে আনার সময় এসেছে। আসুন আমরা এই সন্দেহজনক প্রকারগুলিকে মোকাবেলা করি।

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

অনেকেই জানেন যে 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 তুচ্ছ বিষয়ে সময় নষ্ট করতে পছন্দ করে না। এই ক্রম Smallint উপর ভিত্তি করে কি? int, কোন কম! অতএব, উপরের ক্যোয়ারীটি চালানোর চেষ্টা করার সময়, ডাটাবেসটি অন্য কোন পূর্ণসংখ্যার ধরনে ছোট ছোট কাস্ট করার চেষ্টা করে এবং দেখে যে এই ধরনের বেশ কয়েকটি কাস্ট থাকতে পারে। কোন কাস্ট নির্বাচন করতে? তিনি এই সিদ্ধান্ত নিতে পারেন না, এবং তাই একটি ত্রুটি সঙ্গে ক্র্যাশ.

ফাইল নম্বর দুই। "char"/char/varchar/টেক্সট

চরিত্রের ধরনেও বেশ কিছু অদ্ভুততা রয়েছে। আসুন তাদেরও জেনে নেওয়া যাক।

এই কৌশল কি ধরনের?

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 কমান্ডের সাথে বিশ্লেষণ করুন), যেহেতু এই বিষয়ে অস্পষ্টতা খুব ব্যয়বহুল হতে পারে।

আপনি এই কোথা থেকে পেয়েছেন?

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

কি ব্যাপার? আসল বিষয়টি হল যে একটি টাইমস্ট্যাম্পটজ টাইপ একটি তারিখের প্রকারে কাস্ট করতে, টাইমজোন সিস্টেম প্যারামিটারের মান ব্যবহার করা হয়, যা টাইপ রূপান্তর ফাংশনটিকে একটি কাস্টম প্যারামিটারের উপর নির্ভর করে, যেমন অস্থির এই ধরনের ফাংশন সূচক অনুমোদিত নয়. এই ক্ষেত্রে, আপনাকে অবশ্যই স্পষ্টভাবে নির্দেশ করতে হবে যে কোন সময় অঞ্চলে টাইপ কাস্ট করা হয়েছে।

যখন এখন আর এখন একেবারেই নেই

আমরা এখন () বর্তমান তারিখ/সময় ফেরত দিতে অভ্যস্ত, সময় অঞ্চল বিবেচনা করে। কিন্তু নিম্নলিখিত প্রশ্নগুলি দেখুন:

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}

এসকিউএল-এ উত্থাপিত সাধারণ মানুষ হিসাবে, আমরা আশা করি এই অভিব্যক্তিটির ফলাফল NULL হবে। কিন্তু সেখানে ছিল না। একটি অ্যারে ফেরত দেওয়া হয়. কেন? কারণ এই ক্ষেত্রে বেস NULL কে একটি পূর্ণসংখ্যা অ্যারেতে কাস্ট করে এবং স্পষ্টভাবে array_cat ফাংশনকে কল করে। কিন্তু এটি এখনও অস্পষ্ট রয়ে গেছে কেন এই "অ্যারে বিড়াল" অ্যারে রিসেট করে না। এই আচরণ এছাড়াও শুধু মনে রাখা প্রয়োজন.

সারসংক্ষেপ। অদ্ভুত জিনিস প্রচুর আছে. তাদের মধ্যে বেশিরভাগই, স্পষ্টতই অনুপযুক্ত আচরণ সম্পর্কে কথা বলার মতো সমালোচনামূলক নয়। এবং অন্যদের ব্যবহারের সহজতা বা নির্দিষ্ট পরিস্থিতিতে তাদের প্রযোজ্যতার ফ্রিকোয়েন্সি দ্বারা ব্যাখ্যা করা হয়। তবে একই সঙ্গে রয়েছে নানা চমক। অতএব, আপনি তাদের সম্পর্কে জানতে হবে. আপনি যদি কোনও ধরণের আচরণে অন্য কিছু অদ্ভুত বা অস্বাভাবিক খুঁজে পান তবে মন্তব্যে লিখুন, আমি তাদের উপর উপলব্ধ ডসিয়ার যোগ করতে পেরে খুশি হব।

উত্স: www.habr.com