> On 22 Feb 2018, at 05:12, Tom Lane <t...@sss.pgh.pa.us> wrote: > > Daniel Gustafsson <dan...@yesql.se> writes: >> On 21 Feb 2018, at 21:41, Tom Lane <t...@sss.pgh.pa.us> wrote: >>> I can't think of one; but I wonder if it's worth working a bit harder and >>> removing the fixed limit altogether, probably by using a PQExpBuffer. >>> If you've hit 1024 today, somebody will bump up against 2048 tomorrow. > >> The thought did cross my mind, but I opted for the simple hack first. I can >> take a stab at using a PQExpBuffer to see where that leads. > > Another idea is just to teach addlitchar to realloc the buffer bigger > when necessary.
I think this is the best approach for the task, the attached patch changes the static allocation to instead realloc when required. Having an upper limit on the allocation seemed like a good idea to me, but perhaps it’s overthinking and complicating things for no good reason. cheers ./daniel
0001-Grow-isolation-spec-scanner-buffer-on-large-SQL-step.patch
Description: Binary data
