On Sat, Oct 29, 2011 at 3:35 PM, Tom Lane <t...@sss.pgh.pa.us> wrote: > Robert Haas <robertmh...@gmail.com> writes: >> I've committed this, after a good deal of hacking on the comments, >> some coding style cleanup, and one bug fix: > > Ummm ... why do the incrementer functions think they need to restore the > previous value on failure? AFAICS that's a waste of code and cycles, > since there is only one caller and it doesn't care in the least.
Well, it might not be strictly necessary for pg_utf8_increment() and pg_eucjp_increment(), but it's clearly necessary for the generic incrementer function for exactly the same reason it was needed in the old coding. I suppose we could weaken the rule to "you must leave a valid character behind rather than a bunch of bytes that doesn't encode to a character", but the cycle savings are negligible and the current rule seems both simpler and more bullet-proof. > I'm also quite distressed that you ignored my advice to limit the number > of combinations tried. This patch could be horribly slow when dealing > with wide characters, eg think what will happen when starting from > U+10000. Uh, I think it will try at most one character in that position and then truncate away that character entirely, per my last email on this topic (to which you never responded): http://archives.postgresql.org/pgsql-hackers/2011-09/msg01195.php -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
