BUG #14953: pg_blocking_pids / array_length inconsistency
От | steven.winfield@cantabcapital.com |
---|---|
Тема | BUG #14953: pg_blocking_pids / array_length inconsistency |
Дата | |
Msg-id | 20171207144028.21691.76008@wrigleys.postgresql.org обсуждение исходный текст |
Ответы |
Re: BUG #14953: pg_blocking_pids / array_length inconsistency
Re: BUG #14953: pg_blocking_pids / array_length inconsistency |
Список | pgsql-bugs |
The following bug has been logged on the website: Bug reference: 14953 Logged by: Steven Winfield Email address: steven.winfield@cantabcapital.com PostgreSQL version: 10.0 Operating system: Linux Description: It seems as though pg_blocking_pids() can return a zero-length, one-dimensional array whereas users can only create NULL-length, zero-dimensional arrays (even though the type suggests it is one dimensional: 'integer[]') test=# SELECT pg_blocking_pids(pg_backend_pid()), array_length(pg_blocking_pids(pg_backend_pid()), 1), '{}'::integer[], array_length('{}'::integer[], 1); pg_blocking_pids | array_length | int4 | array_length ------------------+--------------+------+-------------- {} | 0 | {} | (1 row) This means that, for example, the code to check for an empty array of PIDs must be special-cased. For what it's worth, I think having array_length('{}'::integer[], 1) = 0 is far more sensible, and making differently-dimensioned empty arrays compare equal (as mentioned previously[1]) is quite confusing. [1] https://www.postgresql.org/message-id/tencent_5D502954744B7F744ED6F34E%40qq.com
В списке pgsql-bugs по дате отправления: