Re: PATCH: pgbench allow '=' in \set

Fabien COELHO <coelho(at)cri(dot)ensmp(dot)fr> writes:
>> Another option, breaking backward compatibility, would be to decide
>> that backslash commands have to be terminated by a semicolon token.

> I do not like it much, as it is inconsistent/incompatible with "psql".

>> [...] multi-line SQL queries. If we wanted to make that work, the best
>> option might be to duplicate the backend lexer into pgbench just as we
>> already do with psql. [...]
>>
>> I somewhat lean toward this second option, because I think it will be
>> a lot more convenient in the long run. We'll probably get some
>> complains about breaking people's pgbench scripts, but I'd personally
>> be prepared to accept that as the price of progress.

> For an actual lexer: currently there is no real lexer for SQL commands in
> pgbench, the line is just taken as is, so that would mean adding another one,
> although probably a simplified one would do.

Probably not; we'd have to borrow psql's, hook line and sinker. Even if
you could come up with something creative that only failed occasionally,
it would be better from a maintenance perspective if it were as much
like the existing lexers as possible.

(In this context it's worth pointing out that we already have trouble
with keeping psql's and ecpg's lexers in step with the core code.
Adding yet another one, not quite like any of the other ones, doesn't
seem appetizing. If flex were better at factorizing .l files maybe
this wouldn't be quite so painful, but it ain't :-()

I tend to agree with the bottom line that that's just more complication
than is justified. I sympathize with Robert's dislike for backslash
continuations; but doing it the other way would be a huge amount of
up-front work and a nontrivial amount of continuing maintenance, for which
we would not get thanks from users but rather bitching about how we broke
their scripts. Seems like a lose-lose situation.

regards, tom lane