Skip site navigation (1) Skip section navigation (2)

Re: [v9.2] make_greater_string() does not return a string in some cases

From: Robert Haas <robertmhaas(at)gmail(dot)com>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: horiguchi(dot)kyotaro(at)oss(dot)ntt(dot)co(dot)jp, pgsql-hackers(at)postgresql(dot)org
Subject: Re: [v9.2] make_greater_string() does not return a string in some cases
Date: 2011-10-29 20:15:16
Message-ID: CA+Tgmobs+-oxMrps_rfOFwx_7FknFd2qwnwvGTSiv1tS=CXUrQ@mail.gmail.com (view raw or flat)
Thread:
Lists: pgsql-bugspgsql-hackers
On Sat, Oct 29, 2011 at 3:35 PM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> Robert Haas <robertmhaas(at)gmail(dot)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

In response to

Responses

pgsql-hackers by date

Next:From: Mr. Aaron W. SwensonDate: 2011-10-29 20:28:57
Subject: Re: Add socket dir to pg_config..?
Previous:From: Robert HaasDate: 2011-10-29 20:07:02
Subject: Re: pg_upgrade if 'postgres' database is dropped

pgsql-bugs by date

Next:From: Tom LaneDate: 2011-10-29 20:36:06
Subject: Re: [v9.2] make_greater_string() does not return a string in some cases
Previous:From: Tom LaneDate: 2011-10-29 19:35:27
Subject: Re: [v9.2] make_greater_string() does not return a string in some cases

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group