"select ('{}'::text[])[1]" returns NULL -- is it correct?
От | Nikolay Samokhvalov |
---|---|
Тема | "select ('{}'::text[])[1]" returns NULL -- is it correct? |
Дата | |
Msg-id | e431ff4c0704090759w19738d43y93815814191deb84@mail.gmail.com обсуждение исходный текст |
Ответы |
Re: "select ('{}'::text[])[1]" returns NULL -- is it correct?
Re: "select ('{}'::text[])[1]" returns NULL -- is it correct? |
Список | pgsql-hackers |
Thinking about XPath's output in cases such as 'SELECT xpath('/a', '<b />');' I've realized that in such cases an empty array should be returned (now we have NULL for such cases). Why? Because database _knows_ that there is no element -- this is not NULL's case ("unknown"). Then I've examined how the work with arrays in Postgres is organized. And now the result of the following query seems to be a little bit strange for me: xmltest=# select ('{}'::text[])[1] IS NULL;?column? ----------t (1 row) As I can see here, when I ask for element that doesn't exist, the database returns NULL for me. Maybe it's well-known issue (and actually I understood this behaviour before), but strictly speaking it seems wrong for me: the database _knows_ that there is no element, so why NULL? Actually, I do not know what output value would be the best for this case (and I understand that it'd be very painful to change the behaviour because of compatibility issues), so my questions are:1. is it worth to trigger at least notice message (WARNING?)for such cases?2. what should I do with XPath function? There is strong analogy between its case and array's case in my mind... Should I leave NULLs, or empty arrays are better? BTW, is there any better way to select empty array as a constant (better then my "'{}'::text[]")? -- Best regards, Nikolay
В списке pgsql-hackers по дате отправления: