Thread: [HACKERS] Ongoing issues with representation of empty arrays
The distinction between the standard representation of '{}' as an array
with zero dimensions and nonstandard representations as a 1-dimensional
array with zero elements has come up in a couple of contexts on the IRC
channel recently.
First is contrib/intarray, _AGAIN_ (see past bugs such as #7730):
select array_dims(('{1,2}'::integer[] & '{3}'));array_dims
------------[1:0]
(1 row)
regression=# select ('{1,2}'::integer[] & '{3}') = '{}';?column?
----------f
(1 row)
Worse, the fact that the fix for #7730 (commit c155f654) only did a
very partial job means that it's now inconsistent:
regression=# select (a - b), (a & c), (a - b) = (a & c)from (values (array[1,2],array[1,2],array[3])) v(a,b,c);?column?
|?column? | ?column?
----------+----------+----------{} | {} | f
(1 row)
I plan to fix this one properly, unless anyone has any objections.
Second is aclitem[], past bug #8395 which was not really resolved; empty
ACLs are actually 1-dim arrays of length 0, and all the ACL functions
insist on that, which means that you can't call aclexplode('{}') for
example:
https://www.postgresql.org/message-id/flat/CA%2BTgmoZdDpTJDUVsgzRhoCctidUqLDyO8bdYwgLD5p8DwHtMcQ%40mail.gmail.com
It's much less clear what to do about this one. Thoughts?
--
Andrew (irc:RhodiumToad)
Second is aclitem[], past bug #8395 which was not really resolved; empty
ACLs are actually 1-dim arrays of length 0, and all the ACL functions
insist on that, which means that you can't call aclexplode('{}') for
example:
https://www.postgresql.org/message-id/flat/CA% 2BTgmoZdDpTJDUVsgzRhoCctidUqLD yO8bdYwgLD5p8DwHtMcQ%40mail. gmail.com
It's much less clear what to do about this one. Thoughts?
After a quick Google search to get a feel for the landscape...
At a high level the Access Control System is a high-risk area - it seems like the above anomaly doesn't outweigh the risk of slogging through and changing the mechanics. But maybe I'm being overly paranoid in my inexperience...
The question I'd have is whether people are doing '{}'::aclitem[] out of habit or because there is no other way, in SQL, to generate an empty ACL array? If its the later we probably should supply one even if its not documented for external use; none of these other functions are.
I.e., a no-arg "newacl" function where: array_length(newacl(), 1) => 0
IOW - the response to Bug # 8395 is to make #3 workable with the correct syntax. That #2 would continue to return false is maybe annoying but unless we are prepared (and capable) of making '{}'::aclitem[] an error I don't see that we should worry about it.
David J.
p.s. A side question is whether a handful of reports and a couple of PGXN extensions suggest that we should consider user-facing documenting some of these things.
Andrew Gierth <andrew@tao11.riddles.org.uk> writes:
> The distinction between the standard representation of '{}' as an array
> with zero dimensions and nonstandard representations as a 1-dimensional
> array with zero elements has come up in a couple of contexts on the IRC
> channel recently.
> First is contrib/intarray, _AGAIN_ (see past bugs such as #7730):
> ...
> I plan to fix this one properly, unless anyone has any objections.
Just to clarify, what do you think is "properly"?
> Second is aclitem[], past bug #8395 which was not really resolved; empty
> ACLs are actually 1-dim arrays of length 0, and all the ACL functions
> insist on that, which means that you can't call aclexplode('{}') for
> example:
> It's much less clear what to do about this one. Thoughts?
My instinct is to be conservative in what you send and liberal in what you
accept. In this context that would probably mean fixing aclitem-related
functions to accept both 0-dimensional and 1-dimensional-0-length inputs.
(Actually, is there a reason to be picky about the input dimensionality at
all, rather than just iterating over whatever the array contents are?)
Also, if we've got any functions that create aclitem[] values, fix them to
generate the standard representation of empty arrays.
regards, tom lane
>>>>> "Tom" == Tom Lane <tgl@sss.pgh.pa.us> writes:
>> First is contrib/intarray, _AGAIN_ (see past bugs such as #7730):>> ...>> I plan to fix this one properly, unless
anyonehas any objections.
Tom> Just to clarify, what do you think is "properly"?
I would say, that any time an intarray function returns an empty result
it should be the standard 0-dimensional representation that every other
array operation uses. The intarray functions all seem already able to
take such values as inputs. Also there should be regression tests for
this (none of intarray's existing tests have any empty arrays at all).
>> Second is aclitem[], past bug #8395 which was not really resolved; empty>> ACLs are actually 1-dim arrays of length
0,and all the ACL functions>> insist on that, which means that you can't call aclexplode('{}') for>> example:>> It's
muchless clear what to do about this one. Thoughts?
Tom> My instinct is to be conservative in what you send and liberal inTom> what you accept. In this context that would
probablymean fixingTom> aclitem-related functions to accept both 0-dimensional andTom> 1-dimensional-0-length
inputs.Tom>(Actually, is there a reason to be picky about the inputTom> dimensionality at all, rather than just
iteratingover whateverTom> the array contents are?)
Currently there is this:
#define ACL_NUM(ACL) (ARR_DIMS(ACL)[0])
which is obviously wrong for dimensions other than exactly 1. I don't
_think_ there's any great obstacle to fixing this; the only code that
would care about number of dimensions would be allocacl, and since
there'd be no obvious reason to preserve the shape of an aclitem[]
anywhere, that could just do 0 or 1 dimensions.
--
Andrew (irc:RhodiumToad)
The distinction between the standard representation of '{}' as an array
with zero dimensions and nonstandard representations as a 1-dimensional
array with zero elements has come up in a couple of contexts on the IRC
channel recently.
Just to add to the listing of annoyances.
The following makes me want some way, in SQL, to create an empty 1-dimensional array ...
SELECT array_agg(e_arr)
FROM ( VALUES (ARRAY['1']::text[]), (ARRAY[]::text[]) ) v (e_arr);
--ERROR: cannot accumulate arrays of different dimensionality
We moved the goals posts nicely with bac27394a1c but not being able to mix empty and non-empty arrays is problematic. Ideally an empty array could become an array of any dimension on-the-fly so that if even explicitly dimensioned input to array_agg is 1-dimensioned then all empty arrays would be promoted to 1-dimension and the resultant output would become two dimensional. unnest'ing such a structure would pose its own challenges though...
David J.
On Mon, Apr 10, 2017 at 11:17 PM, Andrew Gierth <andrew@tao11.riddles.org.uk> wrote: >>>>>> "Tom" == Tom Lane <tgl@sss.pgh.pa.us> writes: > > >> First is contrib/intarray, _AGAIN_ (see past bugs such as #7730): > >> ... > >> I plan to fix this one properly, unless anyone has any objections. > > Tom> Just to clarify, what do you think is "properly"? > > I would say, that any time an intarray function returns an empty result > it should be the standard 0-dimensional representation that every other > array operation uses. The intarray functions all seem already able to > take such values as inputs. Also there should be regression tests for > this (none of intarray's existing tests have any empty arrays at all). Are there any impacts outside of intarray? merlin
On Tue, Apr 11, 2017 at 12:17 AM, Andrew Gierth <andrew@tao11.riddles.org.uk> wrote: >>>>>> "Tom" == Tom Lane <tgl@sss.pgh.pa.us> writes: > > >> First is contrib/intarray, _AGAIN_ (see past bugs such as #7730): > >> ... > >> I plan to fix this one properly, unless anyone has any objections. > > Tom> Just to clarify, what do you think is "properly"? > > I would say, that any time an intarray function returns an empty result > it should be the standard 0-dimensional representation that every other > array operation uses. The intarray functions all seem already able to > take such values as inputs. Also there should be regression tests for > this (none of intarray's existing tests have any empty arrays at all). This all sounds reasonable to me. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company