Re: jsonb crash

I wrote:
> I think this must be a memoize bug.  AFAICS, nowhere in this query
> can we be processing a non-null JSONB value, so what are we doing
> in jsonb_hash?  Something down-stack must have lost the information
> that the Datum is actually null.

After further inspection, "what are we doing in jsonb_hash?" is
indeed a relevant question, but it seems like it's a type mismatch
not a nullness issue.  EXPLAIN VERBOSE shows

   ->  Memoize  (cost=0.01..1.96 rows=1 width=4)
         Output: subq_0.c5
         Cache Key: ref_0.c, ref_0.a
         ->  Subquery Scan on subq_0  (cost=0.00..1.95 rows=1 width=4)
               Output: subq_0.c5
               Filter: (CASE WHEN (subq_0.c5 < 2) THEN NULL::jsonb ELSE NULL::jsonb END ? ref_0.c)
               ->  Limit  (cost=0.00..0.78 rows=78 width=4)
                     Output: (ref_0.a)
                     ->  Function Scan on pg_catalog.generate_series sample_0  (cost=0.00..3.00 rows=300 width=4)
                           Output: ref_0.a
                           Function Call: generate_series(1, 300)

so unless the "Cache Key" output is a complete lie, the cache key
types we should be concerned with are text and integer.  The Datum
that's being passed to jsonb_hash looks suspiciously like it is a
text value '0000', too, which matches the "c" value from the first
row of pagg_tab_ml.  I now think some part of Memoize is looking in
completely the wrong place to discover the cache key datatypes.

			regards, tom lane