Proposed fix for bug #14826 (the invalid empty array business)

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: pgsql-hackers(at)postgreSQL(dot)org
Subject: Proposed fix for bug #14826 (the invalid empty array business)
Date: 2017-09-23 20:26:23
Message-ID: 20570.1506198383@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

I poked around among the callers of construct_[md_]array() and found at
least two more besides ts_lexize() that could build zero-element arrays;
one of very ancient standing is in the pg_prepared_statements view.

So I think we've got a clear hazard here that justifies changing the
behavior of the low-level array functions, rather than expecting every
call site to be on its guard about empty arrays. Accordingly, I propose
the attached patch which makes construct_md_array responsible for getting
this right.

In principle we could now remove code from the places that do take care to
call construct_empty_array instead. But I found only one place where it
really seemed worth removing anything, in ExecEvalArrayExpr.

I'm a little bit scared about back-patching this, as it seems at least
possible that some external code could be broken by the change in what
construct_[md_]array could hand back. Given that some of these bugs
have been in place for ~ten years and nobody noticed till now, seems
like it might be good enough to fix them in HEAD only.

Comments?

regards, tom lane

Attachment Content-Type Size
handle-empty-arrays-correctly-always.patch text/x-diff 2.5 KB

Browse pgsql-hackers by date

  From Date Subject
Next Message Andrew Dunstan 2017-09-23 21:45:46 Re: BUG #14825: enum type: unsafe use?
Previous Message Tom Lane 2017-09-23 19:52:05 Re: BUG #14825: enum type: unsafe use?