Обсуждение: BUG #14953: pg_blocking_pids / array_length inconsistency
BUG #14953: pg_blocking_pids / array_length inconsistency
От
steven.winfield@cantabcapital.com
Дата:
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
On Thu, Dec 7, 2017 at 3:40 PM, <steven.winfield@cantabcapital.com> wrote:
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.
I'm not saying this isn't a bug, but you might want to start using the cardinality() function for comparisons like this.
.m
Thanks - I hadn’t spotted that, even though it was added in 9.4.
Steven.
From: Marko Tiikkaja [mailto:marko@joh.to]
Sent: 07 December 2017 15:07
To: Steven Winfield
Cc: Pg Bugs
Subject: Re: BUG #14953: pg_blocking_pids / array_length inconsistency
On Thu, Dec 7, 2017 at 3:40 PM, <steven.winfield@cantabcapital.com> wrote:
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.
I'm not saying this isn't a bug, but you might want to start using the cardinality() function for comparisons like this.
.m
steven.winfield@cantabcapital.com writes: > 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[]') This has been fixed recently in HEAD: https://git.postgresql.org/gitweb/?p=postgresql.git&a=commitdiff&h=716ea626a but we decided not to back-patch the change. regards, tom lane