అనుమానాస్పద రకాలు

వారి ప్రదర్శనలో అనుమానాస్పదంగా ఏమీ లేదు. అంతేకాక, వారు మీకు బాగా మరియు చాలా కాలం పాటు సుపరిచితులుగా కూడా కనిపిస్తారు. కానీ మీరు వాటిని తనిఖీ చేసే వరకు మాత్రమే. ఇక్కడే వారు తమ కృత్రిమ స్వభావాన్ని ప్రదర్శిస్తారు, మీరు ఊహించిన దానికంటే పూర్తిగా భిన్నంగా పని చేస్తారు. మరియు కొన్నిసార్లు వారు మీ జుట్టును నిలబెట్టే పనిని చేస్తారు - ఉదాహరణకు, వారు వారికి అప్పగించిన రహస్య డేటాను కోల్పోతారు. మీరు వారిని ఎదుర్కొన్నప్పుడు, వారు ఒకరినొకరు తెలియదని వారు పేర్కొన్నారు, అయినప్పటికీ నీడలో వారు ఒకే హుడ్ కింద కష్టపడి పని చేస్తారు. చివరకు వాటిని శుభ్రమైన నీటికి తీసుకురావడానికి ఇది సమయం. ఈ అనుమానాస్పద రకాలతో కూడా వ్యవహరిస్తాము.

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, తక్కువ కాదు! అందువల్ల, పై ప్రశ్నను అమలు చేయడానికి ప్రయత్నిస్తున్నప్పుడు, డేటాబేస్ స్మాల్‌ఇంట్‌ను కొన్ని ఇతర పూర్ణాంక రకానికి ప్రసారం చేయడానికి ప్రయత్నిస్తుంది మరియు అలాంటి అనేక క్యాస్ట్‌లు ఉండవచ్చని చూస్తుంది. ఏ తారాగణాన్ని ఎంచుకోవాలి? ఆమె దీనిని నిర్ణయించుకోలేకపోతుంది, అందువల్ల లోపంతో క్రాష్ అవుతుంది.

ఫైల్ నంబర్ టూ. "చార్"/చార్/వర్చార్/టెక్స్ట్

క్యారెక్టర్ టైపుల్లో కూడా అనేక విచిత్రాలు ఉన్నాయి. వాటిని కూడా తెలుసుకుందాం.

ఇవి ఎలాంటి మాయలు?

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