சந்தேகத்திற்கிடமான வகைகள்

அவர்களின் தோற்றத்தில் சந்தேகம் எதுவும் இல்லை. மேலும், அவர்கள் உங்களுக்கு நன்கு தெரிந்தவர்களாகவும் நீண்ட காலமாகவும் கூட தெரிகிறது. ஆனால் நீங்கள் அவற்றை சரிபார்க்கும் வரை மட்டுமே. இங்குதான் அவர்கள் தங்கள் நயவஞ்சகமான தன்மையைக் காட்டுகிறார்கள், நீங்கள் எதிர்பார்த்ததை விட முற்றிலும் வித்தியாசமாக வேலை செய்கிறார்கள். சில சமயங்களில் அவர்கள் உங்கள் தலைமுடியை நிலைநிறுத்தும் ஒன்றைச் செய்கிறார்கள் - உதாரணமாக, அவர்களிடம் ஒப்படைக்கப்பட்ட ரகசியத் தரவை அவர்கள் இழக்கிறார்கள். நீங்கள் அவர்களை எதிர்கொள்ளும் போது, ​​அவர்கள் ஒருவரையொருவர் தெரியாது என்று கூறுகின்றனர், இருப்பினும் நிழலில் அவர்கள் ஒரே பேட்டையின் கீழ் விடாமுயற்சியுடன் வேலை செய்கிறார்கள். இறுதியாக அவற்றை சுத்தமான தண்ணீருக்கு கொண்டு வர வேண்டிய நேரம் இது. இந்த சந்தேகத்திற்கிடமான வகைகளையும் கையாள்வோம்.

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 பைட்டுகளை எடுக்கும், முடிவை பைடீ வகைக்கு மாற்றுவதன் மூலம் நிரூபிக்கப்பட்டுள்ளது. மேலும் "சார்" வகை இந்த யூனிகோட் பிரதிநிதித்துவத்தின் முதல் பைட்டை மட்டுமே எடுக்கும். பிறகு ஏன் இந்த வகை தேவை? இது சிறப்புத் தேவைகளுக்காகப் பயன்படுத்தப்படும் ஒரு சிறப்பு வகை என்று 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