Re: [HACKERS] Ongoing issues with representation of empty arrays

[Robert Haas]

On Tue, Apr 11, 2017 at 12:17 AM, Andrew Gierth
 wrote:
>> "Tom" == Tom Lane  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


-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

Re: [HACKERS] Ongoing issues with representation of empty arrays

[Merlin Moncure]

On Mon, Apr 10, 2017 at 11:17 PM, Andrew Gierth
 wrote:
>> "Tom" == Tom Lane  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


-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

Re: [HACKERS] Ongoing issues with representation of empty arrays

[David G. Johnston]

On Mon, Apr 10, 2017 at 4:57 PM, Andrew Gierth 
wrote:

> 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.

Re: [HACKERS] Ongoing issues with representation of empty arrays

[Andrew Gierth]

> "Tom" == Tom Lane  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).

 >> 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? 

 Tom> My instinct is to be conservative in what you send and liberal in
 Tom> what you accept.  In this context that would probably mean fixing
 Tom> aclitem-related functions to accept both 0-dimensional and
 Tom> 1-dimensional-0-length inputs.
 
 Tom> (Actually, is there a reason to be picky about the input
 Tom> dimensionality at all, rather than just iterating over whatever
 Tom> 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)


-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

Re: [HACKERS] Ongoing issues with representation of empty arrays

[Tom Lane]

Andrew Gierth  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


-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

Re: [HACKERS] Ongoing issues with representation of empty arrays

[David G. Johnston]

On Mon, Apr 10, 2017 at 5:57 PM, Andrew Gierth 
wrote:

> 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?
>

​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.

[HACKERS] Ongoing issues with representation of empty arrays

[Andrew Gierth]

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)


-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers