From: Tom Lane <tgl@sss.pgh.pa.us>
To: brsaweda@gmail.com
cc: pgsql-bugs@postgresql.org
Subject: Re: BUG #14826: Malformed array dimensions for empty arrays in return
 column "lexemes" of ts_debug()
In-reply-to: <20170923125723.1448.39412@wrigleys.postgresql.org>
References: <20170923125723.1448.39412@wrigleys.postgresql.org>
Comments: In-reply-to brsaweda@gmail.com
	message dated "Sat, 23 Sep 2017 12:57:23 -0000"
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-ID: <26927.1506183968.1@sss.pgh.pa.us>
Date: Sat, 23 Sep 2017 12:26:08 -0400
Message-ID: <26928.1506183968@sss.pgh.pa.us>
Precedence: bulk
Sender: pgsql-bugs-owner@postgresql.org

brsaweda@gmail.com writes:
> test=# SELECT token, lexemes, lexemes = '{}'::text[]
> test-# FROM   ts_debug('a title');
>  token | lexemes | ?column?
> -------+---------+----------
>  a     | {}      | f
>        |         |
>  title | {titl}  | f

> The root of the problem seems to be malformed array dimensions.
> array_dims(lexemes) returns [1:0], while I would expect NULL:

Yeah, that's a bug --- looks like ts_lexize is the root problem.

I'm a bit tempted to fix this centrally by having construct_array()
do something different for zero-dimensioned input, rather than
putting a special case into ts_lexize().  We've been bitten by
this type of insect a few times too many.  The question is
whether there's any code that relies on being able to construct
such malformed arrays ...

			regards, tom lane


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