On Sat, Oct 29, 2011 at 3:35 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
> Robert Haas <robertmhaas@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