Re: [HACKERS] Ongoing issues with representation of empty arrays - Mailing list pgsql-hackers

From Tom Lane
Subject Re: [HACKERS] Ongoing issues with representation of empty arrays
Date
Msg-id 31860.1491882628@sss.pgh.pa.us
Whole thread Raw
In response to [HACKERS] Ongoing issues with representation of empty arrays  (Andrew Gierth <andrew@tao11.riddles.org.uk>)
Responses Re: [HACKERS] Ongoing issues with representation of empty arrays  (Andrew Gierth <andrew@tao11.riddles.org.uk>)
List pgsql-hackers
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



pgsql-hackers by date:

Previous
From: Osahon Oduware
Date:
Subject: [HACKERS] PostGIS Raster - Loading MrSID format
Next
From: Andrew Gierth
Date:
Subject: Re: [HACKERS] Ongoing issues with representation of empty arrays