සැක සහිත වර්ග

ඔවුන්ගේ පෙනුම ගැන සැක සහිත කිසිවක් නැත. එපමණක්ද නොව, ඔවුන් ඔබට හොඳින් හා දිගු කලක් හුරුපුරුදු බව පෙනේ. නමුත් ඒ ඔබ ඒවා පරීක්ෂා කරන තුරු පමණි. ඔබ බලාපොරොත්තු වූවාට වඩා හාත්පසින්ම වෙනස් ලෙස ක්‍රියා කරමින් ඔවුන් තම ද්‍රෝහී ස්වභාවය පෙන්නුම් කරන්නේ මෙහිදීය. සමහර විට ඔවුන් ඔබේ හිසකෙස් කෙලින් කරන දෙයක් කරයි - උදාහරණයක් ලෙස, ඔවුන්ට පවරා ඇති රහස් දත්ත ඔවුන්ට අහිමි වේ. ඔබ ඔවුන්ට මුහුණ දෙන විට, ඔවුන් පවසන්නේ ඔවුන් එකිනෙකා නොදන්නා බවයි, නමුත් සෙවණෙහි ඔවුන් එකම ආවරණයක් යටතේ වෙහෙස මහන්සි වී වැඩ කළත්. අවසානයේ ඔවුන් පිරිසිදු ජලය වෙත ගෙන ඒමට කාලයයි. අපි මෙම සැක සහිත වර්ග සමඟ ද කටයුතු කරමු.

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 සුළු දේවල් සඳහා කාලය නාස්ති කිරීමට කැමති නැත. smallint මත පදනම් වූ මෙම අනුපිළිවෙල මොනවාද? 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 වෙනිදා, එය ඇගේ මනස අවුල් කරනවා. සාමාන්‍යයෙන් කථා කරන විට, පෙළ ආකෘතියෙන් දින සම්ප්‍රේෂණය කිරීමේදී, දත්ත සමුදාය ඒවා කෙතරම් නිවැරදිව හඳුනාගෙන ඇත්ද යන්න ඔබ ඉතා ප්‍රවේශමෙන් පරීක්ෂා කළ යුතුය (විශේෂයෙන්, SHOW ඩේට් ස්ටයිල් විධානය සමඟ දින විලාස පරාමිතිය විශ්ලේෂණය කරන්න), මන්ද මෙම කාරණයේ අපැහැදිලි ඉතා මිල අධික විය හැකිය.

ඔබ මෙය ලබා ගත්තේ කොහෙන්ද?

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

දත්ත සමුදායට නිශ්චිතව දක්වා ඇති කාලය තේරුම් ගත නොහැක්කේ ඇයි? මක්නිසාද කාල කලාපයට කෙටි යෙදුමක් නොමැත, නමුත් සම්පූර්ණ නමක්, එය අර්ථවත් වන්නේ දිනයක සන්දර්භය තුළ පමණි, මන්ද එය කාල කලාප වෙනස්වීම් වල ඉතිහාසය සැලකිල්ලට ගන්නා අතර එය දිනයක් නොමැතිව ක්‍රියා නොකරයි. කාල රේඛාවේ වචන ප්‍රශ්න මතු කරයි - ක්‍රමලේඛකයා සැබවින්ම අදහස් කළේ කුමක්ද? එමනිසා, ඔබ එය දෙස බැලුවහොත් මෙහි සෑම දෙයක්ම තාර්කික ය.

ඔහුට ඇති වරද කුමක්ද?

තත්වය සිතා බලන්න. ඔබේ වගුවේ Timestampz වර්ගය සහිත ක්ෂේත්‍රයක් ඇත. ඔබට එය සුචිගත කිරීමට අවශ්‍යයි. නමුත් මෙම ක්ෂේත්‍රයේ දර්ශකයක් ගොඩනැගීම එහි ඉහළ තේරීම නිසා සැමවිටම යුක්ති සහගත නොවන බව ඔබට වැටහේ (මෙම වර්ගයේ සියලුම අගයන් පාහේ අද්විතීය වනු ඇත). එබැවින් වර්ගය දිනයකට දැමීමෙන් දර්ශකයේ තේරීම අඩු කිරීමට ඔබ තීරණය කරයි. ඔබට පුදුමයක් ලැබෙනු ඇත:

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

කාරණය කුමක් ද? කාරනය වන්නේ කාලසීමාවේ වර්ගයක් දින වර්ගයකට යැවීමට, 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

වර්ග දිගුවකදී බිටු එකතු කළ යුත්තේ කුමන පැත්තද? එය වම් පසින් ඇති බව පෙනේ. නමුත් මේ කාරණය සම්බන්ධයෙන් වෙනස් මතයක් ඇත්තේ පදනමට පමණි. ප්‍රවේශම් වන්න: වර්ගයක් වාත්තු කිරීමේදී ඉලක්කම් ගණන නොගැලපේ නම්, ඔබට අවශ්‍ය දේ ඔබට නොලැබෙනු ඇත. මෙය දකුණට බිටු එකතු කිරීම සහ බිටු කැපීම යන දෙකටම අදාළ වේ. එසේම දකුණු පසින්...

ගොනු අංක හය. අරා

NULL පවා වෙඩි තැබුවේ නැත

SELECT ARRAY[1, 2] || NULL

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

SQL මත හැදී වැඩුණු සාමාන්‍ය පුද්ගලයන් ලෙස, මෙම ප්‍රකාශනයේ ප්‍රතිඵලය NULL වනු ඇතැයි අපි අපේක්ෂා කරමු. නමුත් එය එහි නොවීය. අරාවක් ආපසු එවනු ලැබේ. ඇයි? මක්නිසාද යත් මෙම අවස්ථාවේදී පාදය NULL පූර්ණ සංඛ්‍යා අරාවකට විකාශනය කර array_cat ශ්‍රිතය ව්‍යංගයෙන් හඳුන්වයි. නමුත් මෙම "අරාවේ බළලා" අරාව යළි සකසන්නේ නැත්තේ මන්දැයි තවමත් අපැහැදිලිව පවතී. මෙම හැසිරීම ද මතක තබා ගත යුතුය.

සාරාංශ කරන්න. අමුතු දේවල් ඕන තරම් තියෙනවා. ඔවුන්ගෙන් බොහෝ දෙනෙක්, ඇත්ත වශයෙන්ම, නිර්ලජ්ජිත ලෙස නුසුදුසු හැසිරීම් ගැන කතා කිරීමට තරම් විවේචනාත්මක නොවේ. සහ අනෙකුත් ඒවා භාවිතයේ පහසුව හෝ ඇතැම් අවස්ථාවන්හිදී ඒවායේ අදාළ වීමේ වාර ගණන මගින් පැහැදිලි කෙරේ. නමුත් ඒ සමඟම බොහෝ විස්මයන් තිබේ. එමනිසා, ඔබ ඔවුන් ගැන දැන සිටිය යුතුය. ඕනෑම ආකාරයක හැසිරීම් වල වෙනත් අමුතු හෝ අසාමාන්ය දෙයක් ඔබ සොයා ගන්නේ නම්, අදහස් දැක්වීමේදී ලියන්න, ඔවුන් මත ඇති ලේඛනවලට එකතු කිරීමට මම සතුටු වෙමි.

මූලාශ්රය: www.habr.com