Re: PATCH: pgbench allow '=' in \set
От | Robert Haas |
---|---|
Тема | Re: PATCH: pgbench allow '=' in \set |
Дата | |
Msg-id | CA+TgmoYePipV1Cuq96ZS8D5uBtHGWOAUjffhbiWAg-zfV0BqNQ@mail.gmail.com обсуждение исходный текст |
Ответ на | PATCH: pgbench allow '=' in \set (Fabien COELHO <coelho@cri.ensmp.fr>) |
Ответы |
Re: PATCH: pgbench allow '=' in \set
|
Список | pgsql-hackers |
On Thu, May 7, 2015 at 2:18 PM, Fabien COELHO <coelho@cri.ensmp.fr> 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) % (100000 * :scale)) > > seems slightly better than: > > \set id 1 + abs((:id * 1021) % (100000 * :scale)) > > But that is debatable! I would like to debate that. :-) Generally, I don't like optional noise words. A good example of how this can bite you is the whole problem with LOCK TABLE foo. You can also write that as LOCK foo. What if you want to lock something that's not a table? If the word "table" were required, then you could support LOCK VIEW foo or LOCK MATERIALIZED VIEW foo or even LOCK FUNCTION foo(). But because the word TABLE is optional, that syntax creates parser ambiguities. We have not been able to agree on a reasonable solution to this problem, and it has blocked implementation of this important and useful feature for years. While I can't foresee what trouble specifically your proposal might cause, I have become wary of such things. 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 basically just redundant. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company
В списке pgsql-hackers по дате отправления: