သံသယဖြစ်ဖွယ်အမျိုးအစားများ

သူတို့ရဲ့ အသွင်အပြင်နဲ့ ပတ်သက်ပြီး သံသယဖြစ်စရာ ဘာမှမရှိပါဘူး။ ထို့အပြင်၊ ၎င်းတို့သည် သင့်အား ကောင်းစွာရင်းနှီးပြီး အချိန်အကြာကြီးပင် ရင်းနှီးနေပုံရသည်။ ဒါပေမယ့် အဲဒါတွေကို သင်စစ်ဆေးတဲ့အချိန်အထိပဲ ရှိပါသေးတယ်။ ဤနေရာတွင် ၎င်းတို့သည် သင်မျှော်လင့်ထားသည်ထက် လုံးဝကွဲပြားစွာ လုပ်ဆောင်နေသည့် ၎င်းတို့၏ ယုတ်ညံ့သော သဘာဝကို ပြသသည်။ တစ်ခါတစ်ရံတွင် ၎င်းတို့သည် သင့်ဆံပင်ကို အဆုံးထိ ရပ်တည်စေမည့် အရာတစ်ခုကို ပြုလုပ်သည် - ဥပမာ၊ ၎င်းတို့ထံအပ်နှင်းထားသော လျှို့ဝှက်အချက်အလက်များ ဆုံးရှုံးသွားတတ်ပါသည်။ သူတို့နဲ့ရင်ဆိုင်ရတဲ့အခါ မှောင်ရိပ်အောက်မှာ အတူတူ လုံ့လဝီရိယရှိရှိ အလုပ်လုပ်ကြပေမယ့် တစ်ယောက်နဲ့တစ်ယောက် မသိကြဘူးလို့ ဆိုကြပါတယ်။ နောက်ဆုံးတော့ သူတို့ကို ရေသန့်ဆေးဖို့ အချိန်ရောက်ပါပြီ။ ဤသံသယဖြစ်ဖွယ်အမျိုးအစားများကိုလည်း ကိုင်တွယ်ကြပါစို့။

ယုတ္တိဗေဒအားလုံးအတွက် PostgreSQL တွင် ဒေတာစာရိုက်ခြင်းသည် တစ်ခါတစ်ရံတွင် အလွန်ထူးဆန်းသော အံ့သြဖွယ်ကောင်းမှုများကို တင်ပြတတ်ပါသည်။ ဒီဆောင်းပါးမှာ သူတို့ရဲ့ ထူးခြားချက်တချို့ကို ရှင်းလင်းဖို့၊ သူတို့ရဲ့ ထူးဆန်းတဲ့ အပြုအမူတွေရဲ့ အကြောင်းရင်းကို နားလည်ပြီး နေ့စဉ်အလေ့အကျင့်မှာ ပြဿနာမဖြစ်အောင် ဘယ်လိုဖြေရှင်းရမလဲဆိုတာကို နားလည်အောင် ကြိုးစားသွားမှာပါ။ အမှန်အတိုင်းပြောရလျှင် ကျွန်ုပ်သည် ဤဆောင်းပါးကို အကိုးအကားစာအုပ်တစ်မျိုးအဖြစ်လည်းကောင်း၊ အငြင်းပွားဖွယ်ရာကိစ္စများတွင် အလွယ်တကူရည်ညွှန်းနိုင်သော အကိုးအကားစာအုပ်အဖြစ်လည်း ပြုစုခဲ့သည်။ ထို့ကြောင့်၊ သံသယဖြစ်ဖွယ်အမျိုးအစားများမှ အံ့သြဖွယ်ရာအသစ်များကို ရှာဖွေတွေ့ရှိလာသောကြောင့် ၎င်းကို ဖြည့်စွက်သွားမည်ဖြစ်သည်။ ဒါဆို၊ မောပန်းနွမ်းနယ်တဲ့ ဒေတာဘေ့စ် ခြေရာခံကိရိယာတွေ သွားကြည့်ရအောင်။

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 သည် အမျိုးအစားကာစ်တင်ခြင်းအတွက် လုပ်ဆောင်နိုင်သော မှတ်ချက်များကို ခွင့်ပြုကြောင်း လူများစွာသိသည်။ ဆိုလိုသည်မှာ သင်သည် 1::int သာမက int(1) ကိုပါ ညီမျှအောင်ရေးနိုင်သည်။ သို့သော် စကားလုံးများစွာပါသော နာမည်အမျိုးအစားများအတွက် မဟုတ်ပါ။ ထို့ကြောင့်၊ သင်သည် ကိန်းဂဏာန်းတန်ဖိုးတစ်ခုအား လုပ်ဆောင်မှုပုံစံတွင် နှစ်ဆတိကျစေရန် ကာစ်လုပ်လိုပါက၊ ဤအမျိုးအစား float8 ၏ alias ဖြစ်သော SELECT float8(1) ကို အသုံးပြုပါ။

Infinity ထက် ဘာကြီးလဲ။

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 အရ ငွေသည် အစစ်အမှန်ကိန်းဂဏန်းမဟုတ်ပါ။ အချို့သော ပုဂ္ဂိုလ်များ အဆိုအရလည်း ပါပါသည်။ ဂဏန်းအမျိုးအစားကိုသာ ငွေအမျိုးအစားသို့ ကာစ်နိုင်သကဲ့သို့ ငွေအမျိုးအစားကို ကိန်းဂဏာန်းအမျိုးအစားအတွက်သာ ဖြစ်နိုင်ကြောင်း မှတ်သားထားရန်လိုပါသည်။ ယခုမူကား သင့်စိတ်ဆန္ဒအတိုင်း ကစားနိုင်ပြီဖြစ်သည်။ ဒါပေမယ့် ပိုက်ဆံက အတူတူဖြစ်မှာမဟုတ်ဘူး။

Smallint နှင့် sequence မျိုးဆက်

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 သည် အသေးအဖွဲများပေါ်တွင် အချိန်ဖြုန်းခြင်းကို မကြိုက်ပါ။ အသေးအမွှားကို အခြေခံ၍ ဤ sequence များသည် အဘယ်နည်း။ int၊ မနည်းဘူး! ထို့ကြောင့်၊ အထက်ဖော်ပြပါမေးခွန်းကို လုပ်ဆောင်ရန်ကြိုးစားသောအခါ၊ ဒေတာဘေ့စ်သည် အခြားကိန်းပြည့်အမျိုးအစားသို့ အသေးအမွှားကို ကာစ်ရန်ကြိုးစားကာ ထိုသို့သော ကာစ်များစွာရှိနိုင်သည်ကို တွေ့မြင်ရသည်။ ဘယ်ကားကို ရွေးမလဲ။ ဒါကို သူမ မဆုံးဖြတ်နိုင်တာကြောင့် အမှားတစ်ခုနဲ့ ပျက်ကျသွားတယ်။

ဖိုင်နံပါတ်နှစ်။ "char"/char/varchar/စာသား

အက္ခရာအမျိုးအစားများတွင်လည်း ထူးထူးခြားခြားများစွာရှိသည်။ သူတို့ကိုလည်း သိလိုက်ရအောင်။

ဒါတွေက ဘယ်လိုလှည့်ကွက်တွေလဲ။

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

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

ဒါဘာအမျိုးအစားလဲ၊ ဒါဘယ်လိုလူရွှင်တော်လဲ။ အဲဒါတွေကို မလိုအပ်ပါဘူး... ကိုးကားချက်များပါရှိသော်လည်း၊ ၎င်းသည် သာမန် char ကဲ့သို့ ဟန်ဆောင်သောကြောင့်ဖြစ်သည်။ ၎င်းသည် ကိုးကားမပါဘဲ ပုံမှန် char နှင့် ကွဲပြားသည်၊ အဘယ်ကြောင့်ဆိုသော် ၎င်းသည် string ကိုယ်စားပြုခြင်း၏ ပထမ byte ကိုသာ ထုတ်သည်၊ ပုံမှန် char သည် ပထမစာလုံးကို ထွက်ပေါ်စေပြီး၊ ကျွန်ုပ်တို့၏အခြေအနေတွင်၊ ပထမစာလုံးသည် ရလဒ်ကို bytea အမျိုးအစားသို့ပြောင်းလဲခြင်းဖြင့် သက်သေပြထားသည့်အတိုင်း ယူနီကုဒ်ကိုယ်စားပြုမှုတွင် 2 bytes ယူသည့်စာလုံး P ဖြစ်သည်။ “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 တွင် PostgreSQL ရှိ NULL ၏ analogue မဟုတ်သည့် ၎င်း၏ကိုယ်ပိုင် null entity ရှိသည်။ တစ်ချိန်တည်းမှာပင်၊ 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}

၎င်း၏ JSONB အကောင်အထည်ဖော်မှုတွင် PostgreSQL သည် ဂဏန်းအစစ်အမှန်များဖော်မတ်ကို ပြောင်းလဲစေပြီး ၎င်းတို့ကို ဂန္တဝင်ပုံစံသို့ ယူဆောင်လာသည်။ 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 command ဖြင့် datestyle parameter ကို ပိုင်းခြားစိတ်ဖြာပါ)၊ ဤကိစ္စတွင် မသေချာမရေရာမှုများသည် အလွန်စျေးကြီးသောကြောင့် ဖြစ်သည်။

ဒါကို မင်းဘယ်ကရခဲ့တာလဲ။

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

ဒေတာဘေ့စ်သည် တိကျစွာသတ်မှတ်ထားသောအချိန်ကို အဘယ်ကြောင့်နားမလည်နိုင်သနည်း။ စံတော်ချိန်ဇုန်တွင် အတိုကောက်မရှိသော်လည်း၊ အချိန်ဇုန်ပြောင်းလဲမှုများ၏သမိုင်းကြောင်းကို ထည့်သွင်းစဉ်းစားသောကြောင့် ရက်စွဲတစ်ခု၏အခြေအနေတွင်သာ အဓိပ္ပာယ်ရှိသော အမည်အပြည့်အစုံဖြစ်ပြီး၊ ၎င်းသည် ရက်စွဲမပါဘဲ အလုပ်မလုပ်သောကြောင့်ဖြစ်သည်။ ပြီးတော့ time line ရဲ့ စကားလုံးအသုံးအနှုန်းက မေးခွန်းတွေ ထွက်လာတယ် - programmer က ဘာကို ဆိုလိုတာလဲ။ ထို့ကြောင့် ဤနေရာတွင် ကြည့်လျှင် အရာအားလုံးသည် ယုတ္တိရှိသည်။

သူဘာဖြစ်နေတာလဲ။

အခြေအနေကို မြင်ယောင်ကြည့်ပါ။ 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 now(); အမှန်တကယ်တော့ လက်ရှိအချိန်မဟုတ်ပါ... ရိုးရိုးသားသား လက်ရှိအချိန်ကို ရယူလိုပါက clock_timestamp() လုပ်ဆောင်ချက်ကို အသုံးပြုရန်လိုအပ်ပါသည်။

ဖိုင်နံပါတ်ငါး။ နည်းနည်း

နည်းနည်းတော့ ထူးဆန်းတယ်။

SELECT '111'::bit(4)

 bit
bit(4)
------
1110

အမျိုးအစားတိုးချဲ့မှုတွင် မည်သည့်ဘက်ခြမ်းကို ထည့်သင့်သနည်း။ လက်ဝဲဘက်တွင်ရှိပုံရသည်။ ဒါပေမယ့် အခြေခံကပဲ ဒီကိစ္စနဲ့ ပတ်သက်ပြီး ကွဲပြားတဲ့ သဘောထားရှိပါတယ်။ သတိထားပါ- အမျိုးအစားတစ်ခုကို ကာစ်လုပ်သည့်အခါ ဂဏန်းအရေအတွက်နှင့် မကိုက်ညီပါက၊ သင်အလိုရှိသောအရာကို ရရှိမည်မဟုတ်ပါ။ ၎င်းသည် ညာဘက်တွင် bits ပေါင်းထည့်ခြင်းနှင့် ဖြတ်တောက်ခြင်း bits နှစ်ခုလုံးအတွက် အကျုံးဝင်ပါသည်။ ညာဘက်မှာလည်း...

ဖိုင်နံပါတ်ခြောက်။ အခင်းများ

NULL ပင်လျှင် မပစ်ခဲ့ပါ။

SELECT ARRAY[1, 2] || NULL

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

SQL တွင် မွေးမြူထားသော သာမန်လူများအနေဖြင့် ဤဖော်ပြချက်၏ ရလဒ်သည် NULL ဖြစ်မည်ဟု ကျွန်ုပ်တို့ မျှော်လင့်ပါသည်။ ဒါပေမယ့်အဲဒီမှာမဟုတ်ပါဘူး။ array တစ်ခုကို ပြန်ပေးသည်။ အဘယ်ကြောင့်? ဤကိစ္စတွင်၊ အခြေခံသည် NULL ကို ကိန်းပြည့် array တစ်ခုသို့ ချပေးပြီး array_cat လုပ်ဆောင်ချက်ကို သွယ်ဝိုက်စွာခေါ်ဆိုသောကြောင့် ဖြစ်သည်။ သို့သော် ဤ "array cat" သည် array ကို အဘယ်ကြောင့် ပြန်လည်မသတ်မှတ်ရသနည်းဆိုသည်ကို ရှင်းရှင်းလင်းလင်း မသိရသေးပါ။ ဒီအမူအကျင့်ကိုလည်း မှတ်သားထားဖို့ လိုပါတယ်။

အကျဉ်းချုပ်ပါ။ ထူးဆန်းတာတွေ အများကြီးရှိတယ်။ အများစုမှာ မသင့်လျော်သော အပြုအမူများကို ပြောင်ပြောင်တင်းတင်း ပြောဆိုခြင်းအတွက် အလွန်အပြစ်တင်ဝေဖန်ခြင်း မရှိကြပေ။ အချို့သော အခြေအနေများတွင် အသုံးပြုရလွယ်ကူခြင်း သို့မဟုတ် ၎င်းတို့၏အသုံးချနိုင်မှု အကြိမ်ရေဖြင့် ရှင်းပြထားပါသည်။ ဒါပေမယ့် တစ်ချိန်တည်းမှာ အံ့သြစရာတွေ အများကြီးရှိပါတယ်။ ထို့ကြောင့် ၎င်းတို့အကြောင်း သိထားရန် လိုအပ်ပါသည်။ အမျိုးအစားအလိုက် ထူးထူးခြားခြား သို့မဟုတ် ထူးထူးခြားခြား အပြုအမူတစ်ခုခုကို တွေ့ရှိပါက comment တွင် ရေးပေးခဲ့ပါ၊ ၎င်းတို့တွင် ရရှိနိုင်သော စာရွက်စာတမ်းများကို ထည့်သွင်းရန် ဝမ်းမြောက်မိပါသည်။

source: www.habr.com