Re: Ongoing issues with representation of empty arrays

On Mon, Apr 10, 2017 at 5:57 PM, Andrew Gierth <andrew(at)tao11(dot)riddles(dot)org(dot)uk>
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.