On Mon, Nov 16, 2015 at 8:35 AM, Tom Lane <t...@sss.pgh.pa.us> wrote: > I wrote: >> I experimented with using a hash table to avoid the O(N^2) behavior. >> This seems to work quite well, and I think it doesn't change the results >> (leastwise, it does not break the regression tests). > > Looking at this again in the light of morning, it occurred to me that it's > pretty broken in the face of long (approaching NAMEDATALEN) input > identifiers. If the de-duplication digits are beyond the NAMEDATALEN > threshold, it would actually get into an infinite loop because hash_search > would ignore them as not part of the key. That can be fixed by truncating > the name appropriately. > > However: actually, this code had a problem already with long identifiers. > What happened before was that it would blithely add digits and thereby > produce an overlength identifier, which indeed looks distinct from the > other ones in the query --- but if we're dumping a view/rule, the > identifier won't be distinct after truncation, which means that > dump/reload could fail, or even worse, silently produce something with > different semantics than intended. > > So the attached updated patch takes care of that problem, not only for > relation names but also for column names. > > I had been leaning towards not back-patching this, but I now feel that > we must back-patch at least the truncation fix, and we probably might as > well back-patch it in toto. Comments?
As-committed it has solved the problem, as best as I can tell. Thanks, Jeff -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
