Re: "select ('{}'::text[])[1]" returns NULL -- is it correct?
От | Tom Lane |
---|---|
Тема | Re: "select ('{}'::text[])[1]" returns NULL -- is it correct? |
Дата | |
Msg-id | 28240.1176131903@sss.pgh.pa.us обсуждение исходный текст |
Ответ на | "select ('{}'::text[])[1]" returns NULL -- is it correct? ("Nikolay Samokhvalov" <samokhvalov@gmail.com>) |
Ответы |
Re: "select ('{}'::text[])[1]" returns NULL -- is it correct?
|
Список | pgsql-hackers |
"Nikolay Samokhvalov" <samokhvalov@gmail.com> writes: > 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? This is operating as designed, per http://www.postgresql.org/docs/8.2/static/arrays.html : An array subscript expression will return null if either the array : itself or any of the subscript expressions are null. Also, null is : returned if a subscript is outside the array bounds (this case does not : raise an error). For example, if schedule currently has the dimensions : [1:3][1:2] then referencing schedule[3][3] yields NULL. Similarly, an : array reference with the wrong number of subscripts yields a null rather : than an error. AFAIR it's always been like that, so changing it seems exceedingly likely to break some peoples' applications. It's not completely without analogies in SQL, anyway: consider the behavior of INSERT when fewer columns are provided than the table has. Pretending that elements outside the stored range of the array are null is not all that different from silently adding nulls to a row-to-be-stored. regards, tom lane
В списке pgsql-hackers по дате отправления: