[...] 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
Hello Robert,
Also, having ";" as a end of commands could also help by allowing multiline
commands, but that would break compatibility. Maybe allowing continuations
(\\\n) would be an acceptable compromise.
I loathe violently the convention of using a backslash at the end of a
line, because
Fabien COELHO 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
On Thu, May 14, 2015 at 3:20 AM, Fabien COELHO
wrote:
>> I loathe violently the convention of using a backslash at the end of a
>> line, because it's too easy to write backslash-space-newline or
>> backslash-tab-newline when you meant to write backslash-newline. But maybe
>> we should do it anyway
Hello Robert,
Also, having ";" as a end of commands could also help by allowing multiline
commands, but that would break compatibility. Maybe allowing continuations
(\\\n) would be an acceptable compromise.
I loathe violently the convention of using a backslash at the end of a line,
becaus
On Wed, May 13, 2015 at 3:54 PM, Fabien COELHO wrote:
> Ok. I've marked this one as REJECTED.
>
> Otherwise, I was considering this kind of things:
>
> n := expr
> n, m, p, q := SELECT ...
>
> Also, having ";" as a end of commands could also help by allowing multiline
> commands, but that woul
I also don't like to restate what has already been said. \set at the
beginning of the line tells you that you will be setting a variable.
Adding = or := only restates the same thing. I agree it superficially
looks a little nicer, but I'm not sure it's really going to add
clarity, because it's
On Thu, May 7, 2015 at 2:18 PM, Fabien COELHO wrote:
> Since an expression syntax has been added to pgbench, I find that the
> readability of expressions is not great. An extra '=' improves the situation
> for me:
>
>\set id = 1 + abs((:id * 1021) % (10 * :scale))
>
> seems slightly better
​Would "colon-equal" be more acceptable - like in pl/pgsql?
Hmmm... I would tend to think that is even clearer as a separator than a
mere "=". Too much Pascal in my youth? :-)
Although ":" means beginning of variable name in pgbench, I would not
think that it is an issue because = is not a
Hello Tom,
I've got doubts about this too: it introduces fundamental inconsistency
in pgbench itself, which may come back to bite us later. Who's to say
that '=' will never be a meaningful operator in pgbench expressions?
Hmmm... it would not be an issue as long as '=' is not a unary operato
On Thu, May 7, 2015 at 11:43 AM, Fabien COELHO wrote:
>
> Hello,
>
> \set id = 1 + abs((:id * 1021) % (10 * :scale))
>>>
>>> seems slightly better than:
>>>
>>>\set id 1 + abs((:id * 1021) % (10 * :scale))
>>>
>>
>> It is question :( - it break a consistency with psql
>>
>
> It ac
Hello,
\set id = 1 + abs((:id * 1021) % (10 * :scale))
seems slightly better than:
\set id 1 + abs((:id * 1021) % (10 * :scale))
It is question :( - it break a consistency with psql
It actually "breaks" nothing as it is purely cosmectic:-)
More seriously, I'm not sure that
Pavel Stehule writes:
> 2015-05-07 20:18 GMT+02:00 Fabien COELHO :
>> The attached patch just ignores a leading '=' in a pgbench expression.
> It is question :( - it break a consistency with psql
I've got doubts about this too: it introduces fundamental inconsistency
in pgbench itself, which may
2015-05-07 20:18 GMT+02:00 Fabien COELHO :
>
> Hello devs,
>
> Since an expression syntax has been added to pgbench, I find that the
> readability of expressions is not great. An extra '=' improves the
> situation for me:
>
>\set id = 1 + abs((:id * 1021) % (10 * :scale))
>
> seems slightl
Hello devs,
Since an expression syntax has been added to pgbench, I find that the
readability of expressions is not great. An extra '=' improves the
situation for me:
\set id = 1 + abs((:id * 1021) % (10 * :scale))
seems slightly better than:
\set id 1 + abs((:id * 1021) % (1
15 matches
Mail list logo
