Re: Ongoing issues with representation of empty arrays

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Andrew Gierth <andrew(at)tao11(dot)riddles(dot)org(dot)uk>
Cc: pgsql-hackers(at)postgresql(dot)org
Subject: Re: Ongoing issues with representation of empty arrays
Date: 2017-04-11 03:50:28
Message-ID: 31860.1491882628@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Andrew Gierth <andrew(at)tao11(dot)riddles(dot)org(dot)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

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Andrew Gierth 2017-04-11 04:17:56 Re: Ongoing issues with representation of empty arrays
Previous Message Osahon Oduware 2017-04-11 03:42:37 PostGIS Raster - Loading MrSID format