Re: Fwd: Re: [DOCS] Document Upper Limit for NAMEDATELEN in pgsql 9.5+

On Fri, Jan 8, 2016 at 12:05 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
> Whoever thought this was a good idea:
>
>     StaticAssertStmt(NAMEDATALEN <= MAX_LEVENSHTEIN_STRLEN,
>                      "Levenshtein hinting mechanism restricts NAMEDATALEN");
>
> is nuts.

Then I must be nuts.

> A minimal fix that would not put stumbling blocks in the way of changes
> to NAMEDATALEN is to redefine MAX_LEVENSHTEIN_STRLEN as
> Max(255, NAMEDATALEN).  But I wonder why we have to have an arbitrary limit
> in this code at all.  I trust nobody here believes this is the only O(N^2)
> algorithm in the backend; the others don't have this sort of thing in
> front of them.

The default NAMEDATALEN is of course 64. I didn't feel that the static
assertion was especially restrictive, given that it still leaves
significant headroom. I'm slightly surprised that this cropped up. I
didn't want to presume that the algorithm being O(N^2) was the only
reason for the restriction. This comment seems pretty scary to me:
   /*    * For security concerns, restrict excessive CPU+RAM usage. (This    * implementation uses O(m) memory and has
O(mn)complexity.)    */   if (m > MAX_LEVENSHTEIN_STRLEN ||       n > MAX_LEVENSHTEIN_STRLEN)       ereport(ERROR,
        (errcode(ERRCODE_INVALID_PARAMETER_VALUE),                errmsg("argument exceeds the maximum length of %d
bytes",                      MAX_LEVENSHTEIN_STRLEN)));
 

-- 
Peter Geoghegan