Re: pgbench - allow backslash-continuations in custom scripts

Hello,

At Thu, 24 Dec 2015 07:40:19 +0100 (CET), Fabien COELHO <coelho@cri.ensmp.fr> wrote in
<alpine.DEB.2.10.1512240729160.17411@sto>
>
> Hello Michaël,
>
> >> If I read you correctly, I should cut it out into a new file and
> >> include it. Is it correct?
> >
> > Not really, I meant to see if it would be possible to include this set
> > of routines directly in libpqcommon (as part of OBJS_FRONTEND). This
> > way any client applications could easily reuse it. If we found that
> > what was in psql is now useful to pgbench, I have little doubt that
> > some other folks would make good use of that. I honestly have not
> > looked at the code to see if that's doable or not, but soft-linking
> > directly in pgbench a file of psql will not help future maintenance
> > for sure. This increases the complexity of the code.

Thanks. I understand it and I agree to the last sentense. I don't
want them to be exposed as generic features.

Instaed, I'd like to separate backslash commands from psqlscan.l
and use callbacks to access variables by ":name" syntax (it is a
common syntax between pgbench and psql). Current psqlscan.l
simply exits noticing of leading backslash of backslash commands
to the caller so it would be separated without heavy
surgery. This can put away the ugliness of VariableSpace
overriding.

standard_strings() checks standard_comforming_strins on the
session. This is necessarily called on parsing so it can be moved
out into PsqlScanState.

psql_error() redirects messages according to queryFout and adds
input file information. They are heavily dependent to psql. So
I'd like to make them a callback in PsqlScanState and do fprintf
as the default behavior (=NULL).

These measures will get rid of the ugliness. What do you think
about this?

> Just my 0.02€:
>
> I understand that you suggest some kind of dynamic
> parametrization... this is harder to do and potentially as fragile as
> the link/ifdef option, with an undertermined set of callbacks to
> provide... the generic version would be harder to debug, and this
> approach would prevent changing lexer options. Basically I'm not sure
> that doing all that for improving the handling of pgbench scripts is
> worth the effort. I would go with the simpler option.

Undetermined set of callbacks would do so but it seems to me a
set of few known functions to deal with as shown above. The
shared lexer deals only with SQL and a backslash at the top of a
command.

regards,

--
Kyotaro Horiguchi
NTT Open Source Software Center