Re: PATCH: pgbench allow '=' in \set - Mailing list pgsql-hackers

From David G. Johnston
Subject Re: PATCH: pgbench allow '=' in \set
Date
Msg-id CAKFQuwYPWh+DRboHdA7+ELpEm=weU45fc=ATTjFLHThG8PV_Dw@mail.gmail.com
Whole thread Raw
In response to Re: PATCH: pgbench allow '=' in \set  (Fabien COELHO <coelho@cri.ensmp.fr>)
Responses Re: PATCH: pgbench allow '=' in \set  (Fabien COELHO <coelho@cri.ensmp.fr>)
List pgsql-hackers
On Thu, May 7, 2015 at 11:43 AM, Fabien COELHO <coelho@cri.ensmp.fr> wrote:

Hello,

   \set id = 1 + abs((:id * 1021) % (100000 * :scale))

seems slightly better than:

   \set id 1 + abs((:id * 1021) % (100000 * :scale))

It is question :( - it break a consistency with psql

It actually "breaks" nothing as it is purely cosmectic:-)


​Would "colon-equal" be more acceptable - like in pl/pgsql?

Even if "=" becomes a valid operator I would have to think it is a binary operator and so its position at the start of an expression would still be unambiguous as to whether it is cosmetic or functional.
 
More seriously, I'm not sure that having a apparent syntatic homogeneity between psql and pgbench should be a requirement, but that is a point worth raising.

The syntax are not really the same anyway: for instance "\set" and "\set NAME" means something for psql but not for pgbench.

Moreover the "\set [NAME [VALUE]]" syntax of psql does not allow an expression, so it stays quite readable as it is, a situation not comparable to pgbench with expressions.


​This seems logical though having never used pgbench or compared them in this manner...

The idea of an actual symbol separating the variable and the expression seems worthwhile to add even in the face of "inconsistency" - which itself should possibly be improved by yet additional changes.

David J.
 


pgsql-hackers by date:

Previous
From: Fabien COELHO
Date:
Subject: Re: PATCH: pgbench allow '=' in \set
Next
From: Fabien COELHO
Date:
Subject: Re: PATCH: pgbench allow '=' in \set