ਸ਼ੱਕੀ ਕਿਸਮ

ਉਨ੍ਹਾਂ ਦੀ ਦਿੱਖ ਬਾਰੇ ਕੁਝ ਵੀ ਸ਼ੱਕੀ ਨਹੀਂ ਹੈ. ਇਸ ਤੋਂ ਇਲਾਵਾ, ਉਹ ਤੁਹਾਨੂੰ ਚੰਗੀ ਤਰ੍ਹਾਂ ਅਤੇ ਲੰਬੇ ਸਮੇਂ ਤੋਂ ਜਾਣੂ ਵੀ ਜਾਪਦੇ ਹਨ. ਪਰ ਇਹ ਉਦੋਂ ਤੱਕ ਹੈ ਜਦੋਂ ਤੱਕ ਤੁਸੀਂ ਉਨ੍ਹਾਂ ਦੀ ਜਾਂਚ ਨਹੀਂ ਕਰਦੇ. ਇਹ ਉਹ ਥਾਂ ਹੈ ਜਿੱਥੇ ਉਹ ਆਪਣੇ ਧੋਖੇਬਾਜ਼ ਸੁਭਾਅ ਨੂੰ ਦਰਸਾਉਂਦੇ ਹਨ, ਤੁਹਾਡੀ ਉਮੀਦ ਨਾਲੋਂ ਬਿਲਕੁਲ ਵੱਖਰੇ ਢੰਗ ਨਾਲ ਕੰਮ ਕਰਦੇ ਹਨ. ਅਤੇ ਕਈ ਵਾਰ ਉਹ ਅਜਿਹਾ ਕੁਝ ਕਰਦੇ ਹਨ ਜਿਸ ਨਾਲ ਤੁਹਾਡੇ ਵਾਲ ਸਿਰੇ 'ਤੇ ਖੜ੍ਹੇ ਹੁੰਦੇ ਹਨ - ਉਦਾਹਰਣ ਵਜੋਂ, ਉਹ ਉਨ੍ਹਾਂ ਨੂੰ ਸੌਂਪਿਆ ਗਿਆ ਗੁਪਤ ਡੇਟਾ ਗੁਆ ਦਿੰਦੇ ਹਨ। ਜਦੋਂ ਤੁਸੀਂ ਉਹਨਾਂ ਦਾ ਸਾਹਮਣਾ ਕਰਦੇ ਹੋ, ਤਾਂ ਉਹ ਦਾਅਵਾ ਕਰਦੇ ਹਨ ਕਿ ਉਹ ਇੱਕ ਦੂਜੇ ਨੂੰ ਨਹੀਂ ਜਾਣਦੇ, ਹਾਲਾਂਕਿ ਪਰਛਾਵੇਂ ਵਿੱਚ ਉਹ ਉਸੇ ਹੁੱਡ ਦੇ ਹੇਠਾਂ ਸਖ਼ਤ ਮਿਹਨਤ ਕਰਦੇ ਹਨ. ਆਖਰਕਾਰ ਉਨ੍ਹਾਂ ਨੂੰ ਸਾਫ਼ ਪਾਣੀ ਵਿੱਚ ਲਿਆਉਣ ਦਾ ਸਮਾਂ ਆ ਗਿਆ ਹੈ। ਆਓ ਇਨ੍ਹਾਂ ਸ਼ੱਕੀ ਕਿਸਮਾਂ ਨਾਲ ਵੀ ਨਜਿੱਠੀਏ।

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 ਦੇ ਉਪਨਾਮ ਦੀ ਵਰਤੋਂ ਕਰੋ, ਯਾਨੀ 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 ਹੈ, ਜੋ ਉਸ ਦੇ ਦਿਮਾਗ ਨੂੰ ਉਡਾ ਦਿੰਦਾ ਹੈ। ਆਮ ਤੌਰ 'ਤੇ, ਟੈਕਸਟ ਫਾਰਮੈਟ ਵਿੱਚ ਤਾਰੀਖਾਂ ਨੂੰ ਪ੍ਰਸਾਰਿਤ ਕਰਦੇ ਸਮੇਂ, ਤੁਹਾਨੂੰ ਬਹੁਤ ਧਿਆਨ ਨਾਲ ਜਾਂਚ ਕਰਨ ਦੀ ਜ਼ਰੂਰਤ ਹੁੰਦੀ ਹੈ ਕਿ ਡੇਟਾਬੇਸ ਨੇ ਉਹਨਾਂ ਨੂੰ ਕਿਵੇਂ ਸਹੀ ਢੰਗ ਨਾਲ ਪਛਾਣਿਆ ਹੈ (ਖਾਸ ਤੌਰ 'ਤੇ, SHOW datestyle ਕਮਾਂਡ ਨਾਲ 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 ਨੂੰ ਇੱਕ ਪੂਰਨ ਅੰਕ ਐਰੇ ਵਿੱਚ ਕਾਸਟ ਕਰਦਾ ਹੈ ਅਤੇ ਸਪਸ਼ਟ ਤੌਰ 'ਤੇ ਐਰੇ_ਕੈਟ ਫੰਕਸ਼ਨ ਨੂੰ ਕਾਲ ਕਰਦਾ ਹੈ। ਪਰ ਇਹ ਅਜੇ ਵੀ ਅਸਪਸ਼ਟ ਹੈ ਕਿ ਇਹ "ਐਰੇ ਕੈਟ" ਐਰੇ ਨੂੰ ਰੀਸੈਟ ਕਿਉਂ ਨਹੀਂ ਕਰਦੀ ਹੈ। ਇਸ ਵਿਹਾਰ ਨੂੰ ਵੀ ਯਾਦ ਰੱਖਣ ਦੀ ਲੋੜ ਹੈ।

ਸੰਖੇਪ. ਬਹੁਤ ਸਾਰੀਆਂ ਅਜੀਬ ਚੀਜ਼ਾਂ ਹਨ. ਉਨ੍ਹਾਂ ਵਿੱਚੋਂ ਬਹੁਤੇ, ਬੇਸ਼ੱਕ, ਇੰਨੇ ਨਾਜ਼ੁਕ ਨਹੀਂ ਹਨ ਕਿ ਬੇਰਹਿਮੀ ਨਾਲ ਅਣਉਚਿਤ ਵਿਵਹਾਰ ਬਾਰੇ ਗੱਲ ਕਰਨ। ਅਤੇ ਹੋਰਾਂ ਦੀ ਵਰਤੋਂ ਦੀ ਸੌਖ ਜਾਂ ਕੁਝ ਸਥਿਤੀਆਂ ਵਿੱਚ ਉਹਨਾਂ ਦੀ ਲਾਗੂ ਹੋਣ ਦੀ ਬਾਰੰਬਾਰਤਾ ਦੁਆਰਾ ਵਿਆਖਿਆ ਕੀਤੀ ਗਈ ਹੈ। ਪਰ ਉਸੇ ਸਮੇਂ, ਬਹੁਤ ਸਾਰੇ ਹੈਰਾਨੀਜਨਕ ਹਨ. ਇਸ ਲਈ, ਤੁਹਾਨੂੰ ਉਨ੍ਹਾਂ ਬਾਰੇ ਜਾਣਨ ਦੀ ਜ਼ਰੂਰਤ ਹੈ. ਜੇ ਤੁਹਾਨੂੰ ਕਿਸੇ ਵੀ ਕਿਸਮ ਦੇ ਵਿਵਹਾਰ ਵਿੱਚ ਕੁਝ ਹੋਰ ਅਜੀਬ ਜਾਂ ਅਸਾਧਾਰਨ ਲੱਗਦਾ ਹੈ, ਤਾਂ ਟਿੱਪਣੀਆਂ ਵਿੱਚ ਲਿਖੋ, ਮੈਨੂੰ ਉਹਨਾਂ 'ਤੇ ਉਪਲਬਧ ਡੋਜ਼ੀਅਰਾਂ ਵਿੱਚ ਸ਼ਾਮਲ ਕਰਨ ਵਿੱਚ ਖੁਸ਼ੀ ਹੋਵੇਗੀ.

ਸਰੋਤ: www.habr.com