ປະເພດທີ່ສົງໃສ

ບໍ່ມີຫຍັງສົງໃສກ່ຽວກັບຮູບລັກສະນະຂອງເຂົາເຈົ້າ. ຍິ່ງໄປກວ່ານັ້ນ, ພວກເຂົາເຈົ້າຍັງເບິ່ງຄືວ່າຄຸ້ນເຄີຍກັບທ່ານດີແລະເປັນເວລາດົນນານ. ແຕ່ວ່າພຽງແຕ່ຈົນກວ່າທ່ານຈະກວດເບິ່ງພວກມັນ. ນີ້ແມ່ນບ່ອນທີ່ພວກເຂົາສະແດງໃຫ້ເຫັນລັກສະນະ insidious ຂອງເຂົາເຈົ້າ, ເຮັດວຽກທີ່ແຕກຕ່າງກັນຫມົດກ່ວາທີ່ທ່ານຄາດຫວັງ. ແລະບາງຄັ້ງພວກເຂົາເຮັດບາງສິ່ງບາງຢ່າງທີ່ເຮັດໃຫ້ຜົມຂອງເຈົ້າຢືນຢູ່ປາຍ - ຕົວຢ່າງ, ພວກເຂົາສູນເສຍຂໍ້ມູນລັບທີ່ຖືກມອບໃຫ້. ໃນເວລາທີ່ທ່ານປະເຊີນກັບພວກເຂົາ, ພວກເຂົາອ້າງວ່າພວກເຂົາບໍ່ຮູ້ກັນແລະກັນ, ເຖິງແມ່ນວ່າຢູ່ໃນເງົາພວກເຂົາເຮັດວຽກຫນັກພາຍໃຕ້ຜ້າຄຸມດຽວກັນ. ມັນເຖິງເວລາແລ້ວທີ່ຈະເອົາພວກມັນມາລ້າງນ້ໍາສະອາດ. ໃຫ້ພວກເຮົາຈັດການກັບປະເພດທີ່ຫນ້າສົງໄສເຫຼົ່ານີ້ເຊັ່ນກັນ.

ການພິມຂໍ້ມູນໃນ PostgreSQL, ສໍາລັບເຫດຜົນທັງຫມົດຂອງມັນ, ບາງຄັ້ງກໍ່ມີຄວາມແປກໃຈທີ່ແປກປະຫຼາດຫຼາຍ. ໃນບົດຄວາມນີ້ພວກເຮົາຈະພະຍາຍາມຊີ້ແຈງບາງ quirks ຂອງເຂົາເຈົ້າ, ເຂົ້າໃຈເຫດຜົນສໍາລັບພຶດຕິກໍາທີ່ແປກປະຫລາດຂອງເຂົາເຈົ້າແລະເຂົ້າໃຈວິທີການທີ່ຈະບໍ່ເຂົ້າໄປໃນບັນຫາໃນການປະຕິບັດປະຈໍາວັນ. ເພື່ອບອກຄວາມຈິງ, ຂ້າພະເຈົ້າໄດ້ລວບລວມບົດຄວາມນີ້ເປັນປະເພດຂອງຫນັງສືອ້າງອີງສໍາລັບຕົນເອງ, ຫນັງສືອ້າງອີງທີ່ສາມາດອ້າງອີງໄດ້ງ່າຍໃນກໍລະນີທີ່ມີການຂັດແຍ້ງ. ດັ່ງນັ້ນ, ມັນຈະຖືກຕື່ມຍ້ອນວ່າຄວາມແປກໃຈໃຫມ່ຈາກປະເພດທີ່ຫນ້າສົງໄສໄດ້ຖືກຄົ້ນພົບ. ດັ່ງນັ້ນ, ໄປ, ໂອ້, ບົບຕິດຕາມລຸດຖານຂໍ້ມູນທີ່ບໍ່ອິດເມື່ອຍ!

Dossier ເລກຫນຶ່ງ. ທີ່ແທ້ຈິງ / ຄວາມແມ່ນຍໍາສອງເທົ່າ / ຕົວເລກ / ເງິນ

ມັນຈະເບິ່ງຄືວ່າປະເພດຕົວເລກແມ່ນບັນຫາຫນ້ອຍທີ່ສຸດກ່ຽວກັບຄວາມແປກໃຈໃນພຶດຕິກໍາ. ແຕ່ບໍ່ວ່າມັນເປັນແນວໃດ. ສະນັ້ນໃຫ້ເລີ່ມຕົ້ນດ້ວຍພວກມັນ. ດັ່ງນັ້ນ…

ລືມວິທີການນັບ

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 ອະນຸຍາດໃຫ້ໃຊ້ notation ສໍາລັບການສົ່ງສັນຍານປະເພດ. ນັ້ນແມ່ນ, ທ່ານສາມາດຂຽນບໍ່ພຽງແຕ່ 1:: int, ແຕ່ຍັງ int (1), ເຊິ່ງຈະທຽບເທົ່າ. ແຕ່ບໍ່ແມ່ນສໍາລັບປະເພດທີ່ມີຊື່ປະກອບດ້ວຍຫຼາຍຄໍາ! ດັ່ງນັ້ນ, ຖ້າທ່ານຕ້ອງການສົ່ງຄ່າຕົວເລກໄປຫາປະເພດຄວາມແມ່ນຍໍາສອງເທົ່າໃນຮູບແບບທີ່ເປັນປະໂຫຍດ, ໃຊ້ນາມແຝງຂອງປະເພດນີ້ float8, ນັ້ນແມ່ນ, SELECT float8(1).

ອັນໃດໃຫຍ່ກວ່າອັນເປັນນິດ?

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

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

ເບິ່ງວ່າມັນເປັນແນວໃດ! ມັນປະກົດວ່າມີບາງສິ່ງບາງຢ່າງໃຫຍ່ກວ່າອັນເປັນນິດ, ແລະມັນຄື NaN! ໃນເວລາດຽວກັນ, ເອກະສານ PostgreSQL ເບິ່ງພວກເຮົາດ້ວຍສາຍຕາທີ່ຊື່ສັດແລະອ້າງວ່າ NaN ແມ່ນແນ່ນອນຫຼາຍກ່ວາຕົວເລກອື່ນໆ, ແລະດັ່ງນັ້ນ, infinity. ກົງກັນຂ້າມຍັງເປັນຄວາມຈິງສໍາລັບ -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, ບໍ່ຫນ້ອຍ! ດັ່ງນັ້ນ, ເມື່ອພະຍາຍາມປະຕິບັດການສອບຖາມຂ້າງເທິງ, ຖານຂໍ້ມູນພະຍາຍາມໂຍນ smallint ໄປຫາບາງປະເພດ integer ອື່ນໆ, ແລະເຫັນວ່າອາດຈະມີການໂຍນຫຼາຍ. ຈະເລືອກຕົວລະຄອນໃດ? ນາງບໍ່ສາມາດຕັດສິນໃຈອັນນີ້, ແລະດັ່ງນັ້ນຈິ່ງເກີດຄວາມຜິດພາດ.

ໄຟລ​໌​ທີ່​ສອງ​. "char"/char/varchar/ຂໍ້ຄວາມ

ຄວາມແປກປະຫລາດຈໍານວນຫນຶ່ງຍັງມີຢູ່ໃນປະເພດຕົວອັກສອນ. ໃຫ້ພວກເຮົາຮູ້ຈັກເຂົາເຈົ້າຄືກັນ.

ປະເພດໃດແດ່ຂອງ tricks ເຫຼົ່ານີ້ແມ່ນ?

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

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

"char" ປະເພດໃດແດ່, ນີ້ແມ່ນຕົວລະຄອນປະເພດໃດ? ພວກ​ເຮົາ​ບໍ່​ຈໍາ​ເປັນ​ຕ້ອງ​ສິ່ງ​ນັ້ນ ... ເພາະ​ວ່າ​ມັນ​ທໍາ​ທ່າ​ວ່າ​ຈະ​ເປັນ char ທໍາມະດາ, ເຖິງ​ແມ່ນ​ວ່າ​ມັນ​ຢູ່​ໃນ​ຄໍາ​ເວົ້າ​. ແລະມັນແຕກຕ່າງຈາກ char ປົກກະຕິ, ເຊິ່ງບໍ່ມີວົງຢືມ, ໃນທີ່ມັນອອກພຽງແຕ່ byte ທໍາອິດຂອງການເປັນຕົວແທນຂອງສະຕຣິງ, ໃນຂະນະທີ່ char ປົກກະຕິອອກຕົວອັກສອນທໍາອິດ. ໃນກໍລະນີຂອງພວກເຮົາ, ຕົວອັກສອນທໍາອິດແມ່ນຕົວອັກສອນ P, ເຊິ່ງໃນການສະແດງ unicode ໃຊ້ເວລາເຖິງ 2 bytes, ເປັນຫຼັກຖານໂດຍການປ່ຽນຜົນໄດ້ຮັບເປັນປະເພດ bytea. ແລະປະເພດ "char" ໃຊ້ພຽງແຕ່ byte ທໍາອິດຂອງການສະແດງ unicode ນີ້. ແລ້ວເປັນຫຍັງປະເພດນີ້ຈຶ່ງຈໍາເປັນ? ເອກະສານ 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 ແມ່ນແຕກຕ່າງກັນເລັກນ້ອຍ. ນີ້ແມ່ນຕົວຢ່າງ.

Johnson ແລະ Johnson. ຮູ້ສຶກວ່າຄວາມແຕກຕ່າງ

SELECT 'null'::jsonb IS NULL

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

ສິ່ງແມ່ນວ່າ JSON ມີ entity null ຂອງຕົນເອງ, ເຊິ່ງບໍ່ແມ່ນການປຽບທຽບຂອງ 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 ມັນຖືກເກັບໄວ້ແລ້ວໃນຮູບແບບຂອງໂຄງສ້າງດັດສະນີ, parsed. ນັ້ນແມ່ນເຫດຜົນທີ່ວ່າໃນກໍລະນີທີສອງ, ມູນຄ່າຂອງວັດຖຸໂດຍກຸນແຈ 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 ຖືກນໍາໃຊ້, ເຊິ່ງເຮັດໃຫ້ຫນ້າທີ່ການແປງປະເພດຂຶ້ນກັບພາລາມິເຕີທີ່ກໍາຫນົດເອງ, i.e. ຜັນຜວນ. ຫນ້າທີ່ດັ່ງກ່າວບໍ່ອະນຸຍາດໃຫ້ຢູ່ໃນດັດຊະນີ. ໃນກໍລະນີນີ້, ທ່ານຕ້ອງລະບຸຢ່າງຊັດເຈນວ່າເຂດເວລາໃດທີ່ປະເພດຂອງການໂຍນຖືກປະຕິບັດ.

ໃນເວລາທີ່ໃນປັດຈຸບັນບໍ່ແມ່ນແມ້ກະທັ້ງໃນປັດຈຸບັນຢູ່ໃນທັງຫມົດ

ພວກ​ເຮົາ​ໄດ້​ຖືກ​ນໍາ​ໃຊ້​ໃນ​ປັດ​ຈຸ​ບັນ () ກັບ​ຄືນ​ວັນ​ທີ / ເວ​ລາ​ປະ​ຈຸ​ບັນ​, ໂດຍ​ຄໍາ​ນຶງ​ເຖິງ​ເຂດ​ທີ່​ໃຊ້​ເວ​ລາ​. ແຕ່ເບິ່ງຄໍາຖາມຕໍ່ໄປນີ້:

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

ດ້ານໃດຄວນເພີ່ມ bits ໃນກໍລະນີຂອງການຂະຫຍາຍປະເພດ? ມັນເບິ່ງຄືວ່າຢູ່ເບື້ອງຊ້າຍ. ແຕ່ວ່າພຽງແຕ່ພື້ນຖານມີຄວາມຄິດເຫັນທີ່ແຕກຕ່າງກັນກ່ຽວກັບເລື່ອງນີ້. ລະວັງ: ຖ້າຕົວເລກບໍ່ກົງກັນໃນເວລາສົ່ງສັນຍານປະເພດໃດນຶ່ງ, ເຈົ້າຈະບໍ່ໄດ້ຮັບສິ່ງທີ່ທ່ານຕ້ອງການ. ນີ້ໃຊ້ໄດ້ກັບທັງການເພີ່ມບິດໃສ່ຂວາ ແລະການຕັດບິດ. ຍັງຢູ່ເບື້ອງຂວາ...

ເອກະສານເລກຫົກ. ອາເຣ

ເຖິງແມ່ນວ່າ NULL ບໍ່ໄດ້ຍິງ

SELECT ARRAY[1, 2] || NULL

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

ໃນຖານະເປັນຄົນປົກກະຕິທີ່ຍົກຂຶ້ນມາໃນ SQL, ພວກເຮົາຄາດຫວັງວ່າຜົນໄດ້ຮັບຂອງການສະແດງອອກນີ້ແມ່ນ NULL. ແຕ່ມັນບໍ່ຢູ່ທີ່ນັ້ນ. array ຖືກສົ່ງຄືນ. ເປັນຫຍັງ? ເນື່ອງຈາກວ່າໃນກໍລະນີນີ້ພື້ນຖານໂຍນ NULL ໄປຫາ array integer ແລະເອີ້ນຟັງຊັນ array_cat ໂດຍ implicitly. ແຕ່ມັນຍັງບໍ່ຊັດເຈນວ່າເປັນຫຍັງ "array cat" ນີ້ບໍ່ຕັ້ງ array. ພຶດຕິກໍານີ້ຍັງພຽງແຕ່ຕ້ອງການທີ່ຈະຈື່ຈໍາ.

ສະຫຼຸບ. ມີຫຼາຍສິ່ງທີ່ແປກປະຫຼາດ. ສ່ວນໃຫຍ່ຂອງພວກເຂົາ, ແນ່ນອນ, ແມ່ນບໍ່ສໍາຄັນຫຼາຍທີ່ຈະເວົ້າກ່ຽວກັບພຶດຕິກໍາທີ່ບໍ່ເຫມາະສົມທີ່ຈະແຈ້ງ. ແລະອື່ນ ໆ ໄດ້ຖືກອະທິບາຍໂດຍຄວາມງ່າຍດາຍຂອງການນໍາໃຊ້ຫຼືຄວາມຖີ່ຂອງການນໍາໃຊ້ຂອງເຂົາເຈົ້າໃນບາງສະຖານະການ. ແຕ່ໃນເວລາດຽວກັນ, ມີຄວາມແປກໃຈຫຼາຍ. ເພາະສະນັ້ນ, ທ່ານຈໍາເປັນຕ້ອງຮູ້ກ່ຽວກັບພວກມັນ. ຖ້າທ່ານພົບສິ່ງອື່ນທີ່ແປກປະຫຼາດຫຼືຜິດປົກກະຕິໃນພຶດຕິກໍາຂອງປະເພດໃດກໍ່ຕາມ, ຂຽນໃນຄໍາເຫັນ, ຂ້າພະເຈົ້າຍິນດີທີ່ຈະເພີ່ມເອກະສານທີ່ມີຢູ່ໃນພວກມັນ.

ແຫຼ່ງຂໍ້ມູນ: www.habr.com