Re: pgbench - allow backslash-continuations in custom scripts - Mailing list pgsql-hackers

From Kyotaro HORIGUCHI
Subject Re: pgbench - allow backslash-continuations in custom scripts
Date
Msg-id 20150724.173632.154461612.horiguchi.kyotaro@lab.ntt.co.jp
Whole thread Raw
In response to Re: pgbench - allow backslash-continuations in custom scripts  (Fabien COELHO <coelho@cri.ensmp.fr>)
Responses Re: pgbench - allow backslash-continuations in custom scripts
Re: pgbench - allow backslash-continuations in custom scripts
Re: pgbench - allow backslash-continuations in custom scripts
List pgsql-hackers
Hi, all.

Attatched is the revised version of this patch.

The first patch is not changed from before.

The second is fixed a kind of bug.

Ths third is the new one to allow backslash continuation for
backslash commands.

hoge.sql is the test custom script.

======
At Fri, 24 Jul 2015 07:39:16 +0200 (CEST), Fabien COELHO <coelho@cri.ensmp.fr> wrote in
<alpine.DEB.2.10.1507240731050.12839@sto>
> > - backslash commands is handled as the same as before: multiline
> >  is not allowed.
> 
> Hmm... that is really the feature I wanted to add initially, too bad
> it is the dropped one:-)

Ouch. The story has been derailed somewhere.

Since SQL statments could be multilined without particluar
marker, we cannot implement multilined backslash commands in the
same way..

The attached revised patch allows backslash continuation for
backslash comands. I suppose this is the same as what you did in
behavior. But SQL statements are still can be continued as psql
does.

I'm not satisfied by the design but I don't see another way..

> >
> > I don't have idea how to deal with the copy of psqlscan.[lh] from
> > psql. Currently they are simply the dead copies of those of psql.
> 
> I think that there should be no copies, but it should use relative
> symbolic links so that the files are kept synchronized.

Yeah, I think so but symlinks could harm on git and Windows. The
another way would be make copies it from psql directory. They
live next door to each other.

> > - Modifying psqlscan in psql requires consideration on how it is
> >  used in pgbench.
> 
> Yep, that is one of the reason why I did not want to go this way, bar
> my natural lazyness.

regards,

-- 
Kyotaro Horiguchi
NTT Open Source Software Center

pgsql-hackers by date:

Previous
From: Ildus Kurbangaliev
Date:
Subject: Re: RFC: replace pg_stat_activity.waiting with something more descriptive
Next
From: Etsuro Fujita
Date:
Subject: Re: We need to support ForeignRecheck for late row locking, don't we?