Re: pgbench - allow backslash-continuations in custom scripts

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Fabien COELHO <coelho(at)cri(dot)ensmp(dot)fr>
Cc: Andres Freund <andres(at)anarazel(dot)de>, Heikki Linnakangas <hlinnaka(at)iki(dot)fi>, Josh Berkus <josh(at)agliodbs(dot)com>, PostgreSQL Developers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: pgbench - allow backslash-continuations in custom scripts
Date: 2015-07-03 14:47:20
Message-ID: 28201.1435934840@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Fabien COELHO <coelho(at)cri(dot)ensmp(dot)fr> writes:
>> I'm pretty clearly in favor of doing correct lexing. I think we should
>> generalize that and make it reusable. psql has it's own hacked up
>> version already, there seems little point in having variedly good copies
>> around.

> I must admit that I do not know how to share lexer rules but have
> different actions on them (psql vs sql parser vs ...), as the action code
> is intrinsically intertwined with expressions.

Obviously this is scope creep of the first magnitude, but ISTM that
it would be possible to share a lexer between psql and pgbench, since
in both of them the basic requirement is "break SQL commands apart and
identify newline-terminated backslash commands". If we're gonna break
pgbench's backwards compatibility anyway, there would be a whole lot
to be said for just going over to psql's input parsing rules, lock
stock 'n barrel; and this would be a good way to achieve that.

As it stands, psqlscan.l has some external dependencies on the rest of
psql, but we could perhaps refactor some of those away, and provide dummy
implementations to satisfy others (eg pgbench could provide a dummy
GetVariable() that just always returns NULL).

So I'm imagining symlinking psqlscan.l into src/bin/pgbench and using it
as-is (possibly after refactoring in psql). A possible issue is avoiding
unnecessary invocations of flex, though. Maybe symlinking the .c file
would work better.

regards, tom lane

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Andrew Dunstan 2015-07-03 14:51:14 Re: PostgreSQL 9.5 Alpha 1 build fail with perl 5.22
Previous Message Fujii Masao 2015-07-03 14:44:10 Re: WAL logging problem in 9.4.3?