[ redirecting from -docs, which isn't the best place to discuss code fixes ]
Whoever thought this was a good idea:
StaticAssertStmt(NAMEDATALEN <= MAX_LEVENSHTEIN_STRLEN,
"Levenshtein hinting mechanism restricts NAMEDATALEN");
is 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.
regards, tom lane
------- Forwarded Message
Date: Fri, 08 Jan 2016 14:49:22 -0500
From: Tom Lane <t...@sss.pgh.pa.us>
To: Kevin Day <thekevin...@gmail.com>
cc: pgsql-d...@postgresql.org
Subject: Re: [DOCS] Document Upper Limit for NAMEDATELEN in pgsql 9.5+
Kevin Day <thekevin...@gmail.com> writes:
> Postgresql 9.5+ may now fail to compile if NAMEDATELEN has been set
> absurdly large (In my case, 384).
> The file src/backend/utils/adt/levenshtein.c does a static assert on
> "NAMEDATALEN <= MAX_LEVENSHTEIN_STRLEN" with MAX_LEVENSHTEIN_STRLEN
> currently set to 255.
Hmm. I'm not sure whether 384 is "absurdly large", but I do wonder
why the levenshtein code gets to dictate limits on NAMEDATALEN at all.
Or to put it even more bluntly, I'm not sure that there is anything
whatever about MAX_LEVENSHTEIN_STRLEN that is well thought out. Why not
rip it out and put some CHECK_FOR_INTERRUPTS tests into the loops instead?
regards, tom lane
--
Sent via pgsql-docs mailing list (pgsql-d...@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-docs
------- End of Forwarded Message
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
