> On 21 Feb 2018, at 21:41, Tom Lane <t...@sss.pgh.pa.us> wrote: > > Daniel Gustafsson <dan...@yesql.se> writes: >> When writing an isolation testcase recently I bumped into the 1024 line >> buffer >> size limit in the lexer for my setup block. Adding some stored procedures to >> the test makes it quite easy to break 1024 characters, and while these could >> be >> added as steps it, it’s not a good workaround since the permutation order >> becomes trickier (and more set in stone). As far as I can see in the >> history, >> this limit is chosen as a decent sized buffer and not rooted in a specific >> requirement, so I propose to bump it slightly to 2048 instead (an equally >> arbitrarily chosen number). Is there a reason to keep it at 1024 that I’m >> missing? > > 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. >> I also (again) forgot about the # comments not being allowed inside setup and >> teardown blocks, so patch 0002 proposes adding support for these as the >> documentation implies. Since SQL comments will be counted towards the line >> buffer, and sent with the command, supporting both kinds of comments seems >> reasonable and consistent. > > Hmm, not sure this is a good idea. # is a valid SQL operator name, so > doing this would create some risk of breaking legal queries. Admittedly, > those operators are rare enough that maybe nobody would ever need them in > isolationtester scripts, but I'm not sure that providing an additional > way to spell "comment" is worth that. Good point, didn’t think about that. cheers ./daniel
