From: | Fabien COELHO <coelho(at)cri(dot)ensmp(dot)fr> |
---|---|
To: | Josh Berkus <josh(at)agliodbs(dot)com> |
Cc: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, PostgreSQL Developers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: pgbench - allow backslash-continuations in custom scripts |
Date: | 2015-06-20 07:22:53 |
Message-ID: | alpine.DEB.2.10.1506200913180.31742@sto |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
>> I tend to agree on that bottom line; having this be inconsistent with psql
>> does not seem like a win.
>>
>>> I'm not clear on why we'd need a full SQL lexer.
>>
>> So you don't get fooled by semicolons embedded in string literals or
>> comments.
>
> I take it we ignore those now? I mean, personally, it wouldn't break
> anything for me but since some other benhcmarks involve random text
> generators ....
If backward compatibility is not an issue (I'm surprised:-), and failure
is acceptable in contrived cases, a simple implementation would be to
accumulate lines till one ends with ";\s*$",
Otherwise maybe the "states" management or the lexer are enough (in simple
quotes, in double quotes, in comment, in stuff), so this can implemented
without actually requiring another lexer in pgbench and be robust.
--
Fabien.
From | Date | Subject | |
---|---|---|---|
Next Message | Michael Paquier | 2015-06-20 08:48:31 | Re: The real reason why TAP testing isn't ready for prime time |
Previous Message | Fabien COELHO | 2015-06-20 06:57:57 | Re: checkpointer continuous flushing |