શંકાસ્પદ પ્રકારો

તેમના દેખાવ વિશે શંકાસ્પદ કંઈ નથી. તદુપરાંત, તેઓ તમને સારી રીતે અને લાંબા સમયથી પરિચિત પણ લાગે છે. પરંતુ તે માત્ર ત્યાં સુધી છે જ્યાં સુધી તમે તેમને તપાસો નહીં. આ તે છે જ્યાં તેઓ તેમનો કપટી સ્વભાવ દર્શાવે છે, તમારી અપેક્ષા કરતાં સંપૂર્ણપણે અલગ રીતે કામ કરે છે. અને કેટલીકવાર તેઓ એવું કંઈક કરે છે જેનાથી તમારા વાળ છેડા પર ઊભા રહે છે - ઉદાહરણ તરીકે, તેઓ તેમને સોંપવામાં આવેલ ગુપ્ત ડેટા ગુમાવે છે. જ્યારે તમે તેમનો મુકાબલો કરો છો, ત્યારે તેઓ દાવો કરે છે કે તેઓ એકબીજાને ઓળખતા નથી, જો કે પડછાયાઓમાં તેઓ સમાન હૂડ હેઠળ સખત મહેનત કરે છે. આખરે તેમને સ્વચ્છ પાણીમાં લાવવાનો સમય છે. ચાલો આ શંકાસ્પદ પ્રકારો સાથે પણ વ્યવહાર કરીએ.

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) પણ લખી શકો છો, જે સમકક્ષ હશે. પરંતુ એવા પ્રકારો માટે નહીં કે જેમના નામમાં ઘણા શબ્દો હોય છે! તેથી, જો તમે વિધેયાત્મક સ્વરૂપમાં ચોકસાઇના પ્રકારને બમણી કરવા માટે સંખ્યાત્મક મૂલ્ય કાસ્ટ કરવા માંગતા હો, તો આ પ્રકારના ફ્લોટ8ના ઉપનામનો ઉપયોગ કરો, એટલે કે સિલેક્ટ ફ્લોટ8(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 નાનકડી બાબતો પર સમય બગાડવાનું પસંદ કરતું નથી. સ્મોલિન્ટ પર આધારિત આ સિક્વન્સ શું છે? પૂર્ણાંક, ઓછું નહીં! તેથી, ઉપરોક્ત ક્વેરીનો અમલ કરવાનો પ્રયાસ કરતી વખતે, ડેટાબેઝ અમુક અન્ય પૂર્ણાંક પ્રકારમાં સ્મોલન્ટ કાસ્ટ કરવાનો પ્રયાસ કરે છે, અને જુએ છે કે આવા ઘણા કાસ્ટ હોઈ શકે છે. કઈ કાસ્ટ પસંદ કરવી? તેણી આ નક્કી કરી શકતી નથી, અને તેથી ભૂલ સાથે ક્રેશ થાય છે.

ફાઈલ નંબર બે. "char"/char/varchar/ટેક્સ્ટ

પાત્રના પ્રકારોમાં સંખ્યાબંધ વિચિત્રતાઓ પણ હાજર છે. ચાલો તેમને પણ જાણીએ.

આ કેવા પ્રકારની યુક્તિઓ છે?

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

આપેલ ઉદાહરણ પર એક નજર નાખો. મેં ખાસ કરીને બધા પરિણામોને બાયટી પ્રકારમાં રૂપાંતરિત કર્યા જેથી તે સ્પષ્ટપણે જોઈ શકાય કે ત્યાં શું હતું. વર્ચર(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 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

શા માટે ડેટાબેઝ સ્પષ્ટ રીતે ઉલ્લેખિત સમયને સમજી શકતો નથી? કારણ કે ટાઈમ ઝોનનું સંક્ષિપ્ત નામ નથી, પરંતુ સંપૂર્ણ નામ છે, જે ફક્ત તારીખના સંદર્ભમાં જ અર્થપૂર્ણ છે, કારણ કે તે સમય ઝોનના ફેરફારોના ઇતિહાસને ધ્યાનમાં લે છે, અને તે તારીખ વિના કામ કરતું નથી. અને સમયરેખાના ખૂબ જ શબ્દો પ્રશ્નો ઉભા કરે છે - પ્રોગ્રામરનો ખરેખર અર્થ શું હતો? તેથી, જો તમે તેને જુઓ તો અહીં બધું જ તાર્કિક છે.

તેની સાથે શું ખોટું છે?

પરિસ્થિતિની કલ્પના કરો. તમારી પાસે તમારા ટેબલમાં ટાઇમસ્ટેમ્પટ્ઝ ટાઇપ સાથેનું ક્ષેત્ર છે. તમે તેને અનુક્રમિત કરવા માંગો છો. પરંતુ તમે સમજો છો કે આ ક્ષેત્ર પર અનુક્રમણિકા બનાવવી તેની ઉચ્ચ પસંદગીને કારણે હંમેશા ન્યાયી નથી (આ પ્રકારના લગભગ તમામ મૂલ્યો અનન્ય હશે). તેથી તમે તારીખ પર પ્રકાર કાસ્ટ કરીને ઇન્ડેક્સની પસંદગી ઘટાડવાનું નક્કી કરો છો. અને તમને આશ્ચર્ય થશે:

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;

તારીખ/સમય એ જ પરત કરવામાં આવે છે, પછી ભલેને અગાઉની વિનંતી પછી કેટલો સમય પસાર થઈ ગયો હોય! શું બાબત છે? હકીકત એ છે કે now() એ વર્તમાન સમય નથી, પરંતુ વર્તમાન વ્યવહારનો પ્રારંભ સમય છે. તેથી, તે વ્યવહારમાં બદલાતું નથી. ટ્રાન્ઝેક્શનના અવકાશની બહાર લૉન્ચ કરવામાં આવેલી કોઈપણ ક્વેરી ટ્રાન્ઝેક્શનમાં અસ્પષ્ટ રીતે લપેટાયેલી હોય છે, તેથી જ અમે નોંધતા નથી કે સિમ્પલ SELECT now(); હકીકતમાં, વર્તમાન નથી... જો તમે પ્રમાણિક વર્તમાન સમય મેળવવા માંગતા હો, તો તમારે 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