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;
(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,

---------------------------(end of broadcast)---------------------------
TIP 6: explain analyze is your friend

Reply via email to