ប្រភេទគួរឱ្យសង្ស័យ

មិនមានអ្វីគួរឱ្យសង្ស័យអំពីរូបរាងរបស់ពួកគេទេ។ លើស​ពី​នេះ​ទៅ​ទៀត ពួក​គេ​ហាក់​ដូច​ជា​ស្គាល់​អ្នក​ច្បាស់​ហើយ​ជា​យូរ​មក​ហើយ។ ប៉ុន្តែ​វា​ទាល់តែ​អ្នក​ពិនិត្យ​មើល។ នេះគឺជាកន្លែងដែលពួកគេបង្ហាញពីធម្មជាតិដ៏អាក្រក់របស់ពួកគេ ដោយធ្វើការខុសពីអ្នករំពឹងទុក។ ហើយពេលខ្លះពួកគេធ្វើអ្វីមួយដែលធ្វើឱ្យសក់របស់អ្នកឈរនៅចុងបញ្ចប់ - ឧទាហរណ៍ពួកគេបាត់បង់ទិន្នន័យសម្ងាត់ដែលប្រគល់ឱ្យពួកគេ។ នៅពេលអ្នកប្រឈមមុខនឹងពួកគេ ពួកគេអះអាងថាពួកគេមិនស្គាល់គ្នា ទោះបីជានៅក្នុងស្រមោលពួកគេធ្វើការយ៉ាងលំបាកនៅក្រោមក្រណាត់តែមួយក៏ដោយ។ វាដល់ពេលហើយដើម្បីនាំពួកគេទៅទឹកស្អាត។ អនុញ្ញាតឱ្យយើងដោះស្រាយជាមួយប្រភេទគួរឱ្យសង្ស័យទាំងនេះផងដែរ។

ការវាយបញ្ចូលទិន្នន័យនៅក្នុង 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) ដែលនឹងស្មើនឹង។ ប៉ុន្តែមិនមែនសម្រាប់ប្រភេទដែលឈ្មោះមានពាក្យច្រើននោះទេ! ដូច្នេះ ប្រសិនបើអ្នកចង់បោះតម្លៃជាលេខទៅជាប្រភេទភាពជាក់លាក់ទ្វេដងក្នុងទម្រង់មុខងារ សូមប្រើឈ្មោះក្លែងក្លាយនៃប្រភេទ 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 មិនចូលចិត្តខ្ជះខ្ជាយពេលវេលាលើរឿងតូចតាចទេ។ តើ​លំដាប់​ទាំង​នេះ​មាន​មូលដ្ឋាន​លើ​អ្វី​ខ្លះ? int មិនតិចទេ! ដូច្នេះហើយ នៅពេលព្យាយាមប្រតិបត្តិសំណួរខាងលើ មូលដ្ឋានទិន្នន័យព្យាយាមបោះលេខតូចទៅប្រភេទចំនួនគត់ផ្សេងទៀត ហើយមើលឃើញថាវាអាចមានការខាសបែបនេះជាច្រើន។ តើត្រូវជ្រើសរើសតួមួយណា? នាង​មិន​អាច​សម្រេច​ចិត្ត​រឿង​នេះ​បាន​ទេ ដូច្នេះ​ហើយ​ទើប​មាន​កំហុស។

ឯកសារលេខពីរ។ "char"/char/varchar/អត្ថបទ

ភាពចម្លែកមួយចំនួនក៏មាននៅក្នុងប្រភេទតួអក្សរផងដែរ។ ចូរយើងស្គាល់ពួកគេផងដែរ។

តើល្បិចទាំងនេះជាអ្វី?

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

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

តើ​នេះ​ជា​ប្រភេទ​«​តួ​»​អ្វី​? យើងមិនត្រូវការវាទេ... ព្រោះវាធ្វើពុតជា char ធម្មតា ទោះបីជាវាស្ថិតនៅក្នុងសម្រង់ក៏ដោយ។ ហើយវាខុសគ្នាពី char ធម្មតា ដែលមិនមានសញ្ញាសម្រង់ ដោយវាចេញតែបៃទីមួយនៃការតំណាងខ្សែអក្សរ ខណៈដែល char ធម្មតាចេញតួអក្សរទីមួយ។ ក្នុងករណីរបស់យើង តួអក្សរទីមួយគឺអក្សរ 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

សូមក្រឡេកមើលឧទាហរណ៍ដែលបានផ្តល់ឱ្យ។ ខ្ញុំបានបំប្លែងលទ្ធផលទាំងអស់ទៅជាប្រភេទ bytea ដូច្នេះវាអាចមើលឃើញយ៉ាងច្បាស់នូវអ្វីដែលនៅទីនោះ។ តើ​ចន្លោះ​នៅ​ខាង​ក្រោយ​បន្ទាប់​ពី​ចាក់​ទៅ varchar(6) នៅ​ឯណា? ឯកសារបញ្ជាក់យ៉ាងខ្លីថា៖ "នៅពេលបញ្ចោញតម្លៃតួអក្សរទៅប្រភេទតួអក្សរផ្សេងទៀត ចន្លោះប្រហោងនៅពីក្រោយត្រូវបានលុបចោល។" ការមិនចូលចិត្តនេះត្រូវតែចងចាំ។ ហើយ​ចំណាំ​ថា ប្រសិនបើ​ថេរ​ខ្សែអក្សរ​ដែល​បាន​ដកស្រង់​ត្រូវ​បាន​បោះ​ដោយផ្ទាល់​ទៅ​ប្រភេទ varchar(6) នោះ​ចន្លោះ​នៅ​ពីក្រោយ​ត្រូវ​បាន​រក្សា​ទុក។ អព្ភូតហេតុបែបនេះ។

ឯកសារលេខបី។ json/jsonb

JSON គឺជារចនាសម្ព័ន្ធដាច់ដោយឡែកដែលរស់នៅក្នុងជីវិតផ្ទាល់ខ្លួនរបស់វា។ ដូច្នេះអង្គភាពរបស់វា និង PostgreSQL គឺខុសគ្នាបន្តិចបន្តួច។ នេះគឺជាឧទាហរណ៍។

ចនសុននិងចនសុន។ មានអារម្មណ៍ខុសគ្នា

SELECT 'null'::jsonb IS NULL

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

រឿងនេះគឺថា JSON មានអង្គធាតុទទេរបស់វា ដែលមិនមែនជា analogue នៃ NULL នៅក្នុង PostgreSQL នោះទេ។ ក្នុងពេលជាមួយគ្នា វត្ថុ 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 ដែលធ្វើឲ្យនាងមានការចាប់អារម្មណ៍។ និយាយជាទូទៅ នៅពេលបញ្ជូនកាលបរិច្ឆេទក្នុងទម្រង់អត្ថបទ អ្នកត្រូវពិនិត្យយ៉ាងប្រុងប្រយ័ត្នថាតើមូលដ្ឋានទិន្នន័យបានទទួលស្គាល់ពួកវាត្រឹមត្រូវប៉ុណ្ណា (ជាពិសេស វិភាគប៉ារ៉ាម៉ែត្រ datestyle ជាមួយពាក្យបញ្ជា 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

តើ​មាន​រឿង​អ្វី​កើតឡើង? ការពិតគឺថា ដើម្បីបោះត្រាប្រភេទ 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;

កាលបរិច្ឆេត/ម៉ោង​ត្រូវ​បាន​ត្រឡប់​មក​វិញ​ដដែល ទោះ​បី​ជា​ពេល​វេលា​បាន​កន្លង​ផុត​ទៅ​ប៉ុន្មាន​តាំង​ពី​ការ​ស្នើ​សុំ​លើក​មុន! តើ​មាន​រឿង​អ្វី​កើតឡើង? ការពិតគឺថាឥឡូវនេះ () មិនមែនជាពេលវេលាបច្ចុប្បន្នទេ ប៉ុន្តែជាពេលវេលាចាប់ផ្តើមនៃប្រតិបត្តិការបច្ចុប្បន្ន។ ដូច្នេះវាមិនផ្លាស់ប្តូរនៅក្នុងប្រតិបត្តិការទេ។ រាល់សំណួរដែលបានបើកនៅខាងក្រៅវិសាលភាពនៃប្រតិបត្តិការគឺត្រូវបានរុំនៅក្នុងប្រតិបត្តិការដោយប្រយោល ដែលជាមូលហេតុដែលយើងមិនកត់សំគាល់ថាពេលវេលាដែលត្រលប់មកវិញដោយ SELECT សាមញ្ញឥឡូវនេះ(); តាមពិតមិនមែនបច្ចុប្បន្នទេ... ប្រសិនបើអ្នកចង់ទទួលបានពេលវេលាបច្ចុប្បន្នដោយស្មោះត្រង់ អ្នកត្រូវប្រើមុខងារ 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