Re: Two small patches for the isolationtester lexer

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Daniel Gustafsson <daniel(at)yesql(dot)se>
Cc: PostgreSQL Development <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Two small patches for the isolationtester lexer
Date: 2018-02-21 20:41:56
Message-ID: 32564.1519245716@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Daniel Gustafsson <daniel(at)yesql(dot)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.

> 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.

regards, tom lane

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Peter Eisentraut 2018-02-21 20:45:17 Re: SHA-2 functions
Previous Message Justin Pryzby 2018-02-21 20:28:49 Re: [doc fix] Correct calculation of vm.nr_hugepages