> On 21 Feb 2018, at 21:41, Tom Lane <tgl@sss.pgh.pa.us> wrote:
>
> Daniel Gustafsson <daniel@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