സംശയാസ്പദമായ തരങ്ങൾ

അവരുടെ രൂപത്തിൽ സംശയാസ്പദമായ ഒന്നും തന്നെയില്ല. മാത്രമല്ല, അവ നിങ്ങൾക്ക് വളരെക്കാലമായി പരിചിതമാണെന്ന് തോന്നുന്നു. പക്ഷേ അത് പരിശോധിക്കുന്നത് വരെ മാത്രം. ഇവിടെയാണ് അവർ അവരുടെ വഞ്ചനാപരമായ സ്വഭാവം കാണിക്കുന്നത്, നിങ്ങൾ പ്രതീക്ഷിച്ചതിലും തികച്ചും വ്യത്യസ്തമായി പ്രവർത്തിക്കുന്നു. ചിലപ്പോൾ അവർ നിങ്ങളുടെ തലമുടി നിൽക്കാൻ സഹായിക്കുന്ന എന്തെങ്കിലും ചെയ്യുന്നു - ഉദാഹരണത്തിന്, അവർക്ക് ഭരമേൽപ്പിച്ച രഹസ്യ ഡാറ്റ നഷ്ടപ്പെടും. നിങ്ങൾ അവരെ അഭിമുഖീകരിക്കുമ്പോൾ, അവർ പരസ്പരം അറിയില്ലെന്ന് അവർ അവകാശപ്പെടുന്നു, എന്നിരുന്നാലും നിഴലിൽ അവർ ഒരേ കവറിന് കീഴിൽ കഠിനാധ്വാനം ചെയ്യുന്നു. ഒടുവിൽ അവരെ ശുദ്ധജലത്തിലേക്ക് കൊണ്ടുവരാൻ സമയമായി. ഈ സംശയാസ്പദമായ തരങ്ങളുമായി നമുക്ക് ഇടപെടാം.

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/text

പ്രതീക തരങ്ങളിലും നിരവധി വിചിത്രതകളുണ്ട്. അവരെയും പരിചയപ്പെടാം.

ഇത് എന്ത് തരത്തിലുള്ള തന്ത്രങ്ങളാണ്?

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 ആണെന്ന് അവൾ തീരുമാനിക്കുന്നു, അത് അവളുടെ മനസ്സിനെ തകർത്തു. പൊതുവായി പറഞ്ഞാൽ, ടെക്സ്റ്റ് ഫോർമാറ്റിൽ തീയതികൾ കൈമാറുമ്പോൾ, ഡാറ്റാബേസ് അവ എത്രത്തോളം ശരിയായി തിരിച്ചറിഞ്ഞുവെന്ന് നിങ്ങൾ വളരെ ശ്രദ്ധാപൂർവ്വം പരിശോധിക്കേണ്ടതുണ്ട് (പ്രത്യേകിച്ച്, ഷോ ഡേറ്റ്‌സ്റ്റൈൽ കമാൻഡ് ഉപയോഗിച്ച് ഡേറ്റ്‌സ്റ്റൈൽ പാരാമീറ്റർ വിശകലനം ചെയ്യുക), കാരണം ഈ വിഷയത്തിലെ അവ്യക്തതകൾ വളരെ ചെലവേറിയതാണ്.

നിങ്ങൾക്ക് ഇത് എവിടെ നിന്ന് ലഭിച്ചു?

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;

മുമ്പത്തെ അഭ്യർത്ഥനയ്ക്ക് ശേഷം എത്ര സമയം കഴിഞ്ഞാലും തീയതി/സമയം അതേപടി തിരികെ നൽകും! എന്താണ് കാര്യം? ഇപ്പോൾ () എന്നത് നിലവിലെ സമയമല്ല, നിലവിലെ ഇടപാടിന്റെ ആരംഭ സമയമാണ് എന്നതാണ് വസ്തുത. അതിനാൽ, ഇടപാടിനുള്ളിൽ ഇത് മാറില്ല. ഒരു ഇടപാടിന്റെ പരിധിക്ക് പുറത്ത് സമാരംഭിക്കുന്ന ഏതൊരു അന്വേഷണവും ഒരു ഇടപാടിൽ പരോക്ഷമായി പൊതിഞ്ഞതാണ്, അതിനാലാണ് സമയം ഒരു ലളിതമായ 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