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