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