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 ---------------------------(end of broadcast)--------------------------- TIP 6: explain analyze is your friend