Re: [COMMITTERS] pgsql: Clean up jsonb code. - Mailing list pgsql-hackers

From Tom Lane
Subject Re: [COMMITTERS] pgsql: Clean up jsonb code.
Date
Msg-id 8908.1399674749@sss.pgh.pa.us
Whole thread Raw
In response to Re: [COMMITTERS] pgsql: Clean up jsonb code.  (Peter Geoghegan <pg@heroku.com>)
Responses Re: [COMMITTERS] pgsql: Clean up jsonb code.  (Heikki Linnakangas <hlinnakangas@vmware.com>)
List pgsql-hackers
Peter Geoghegan <pg@heroku.com> writes:
> On Fri, May 9, 2014 at 2:54 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
>> However, what it looks to me like we've got here is a very bad
>> reimplementation of StringInfo buffers.  There is for example no
>> integer-overflow checking here.  Rather than try to bring this code
>> up to speed, I think we should rip it out and use StringInfo.

> Heikki did specifically consider StringInfo buffers and said they were
> not best suited to the task at hand. At the time I thought he meant
> that he'd do something domain-specific to avoid unnecessary geometric
> growth in the size of the buffer (I like to grow buffers to either
> twice their previous size, or just big enough to fit the next thing,
> whichever is larger), but that doesn't appear to be the case. Still,
> it would be good to know what he meant before proceeding. It probably
> had something to do with alignment.

It looks to me like he wanted an API that would let him reserve space
separately from filling it, which is not in stringinfo.c but is surely
easily built on top of it.  For the moment, I've just gotten rid of
the buggy code fragment in favor of calling enlargeStringInfo, which
I trust to be right.

We might at some point want to change the heuristics in
enlargeStringInfo, but two days before beta is not the time for that.
        regards, tom lane



pgsql-hackers by date:

Previous
From: Peter Geoghegan
Date:
Subject: Re: [COMMITTERS] pgsql: Clean up jsonb code.
Next
From: Josh Berkus
Date:
Subject: Commitfest still shows pending patches?