Re: pgbench more operators & functions

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Robert Haas <robertmhaas(at)gmail(dot)com>
Cc: Fabien COELHO <coelho(at)cri(dot)ensmp(dot)fr>, Haribabu Kommi <kommi(dot)haribabu(at)gmail(dot)com>, Amit Kapila <amit(dot)kapila16(at)gmail(dot)com>, Stephen Frost <sfrost(at)snowman(dot)net>, Jeevan Ladhe <jeevan(dot)ladhe(at)enterprisedb(dot)com>, PostgreSQL Developers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: pgbench more operators & functions
Date: 2017-01-24 17:58:16
Views: Raw Message | Whole Thread | Download mbox | Resend email
Lists: pgsql-hackers

Robert Haas <robertmhaas(at)gmail(dot)com> writes:
>> On Fri, Dec 2, 2016 at 1:28 AM, Fabien COELHO <coelho(at)cri(dot)ensmp(dot)fr> wrote:
>>> This decision is both illogical and arbitrary.

>> I disagree. I think his decision was probably based on this email from me:

> (argh, sent too soon)

> Nobody responded to that, and I have not seen any committer say that
> they are in favor of this. Against that, three committers (Tom,
> Stephen, me) have taken the view that they are opposed to at least
> some parts of it. No changes to the patch have resulted from those
> complaints. So this is just submitting the same thing over and over
> again and hoping that the fourth or fifth committer who looks at this
> is going to have a different opinion than the first three, or fail to
> notice the previous discussion.

I concur that this is expanding pgbench's expression language well beyond
what anybody has shown a need for. I'm also concerned that there's an
opportunity cost here, in that the patch establishes a precedence ordering
for its new operators, which we'd have a hard time changing later. That's
significant because the proposed precedence is different from what you'd
get for similarly-named operators on the backend side. I realize that
it's trying to follow the C standard instead, but do we really want to
open that can of worms right now? That's a decision I'd much rather put
off if we need not make it now.

I'd be okay with the parts of this that duplicate existing backend syntax
and semantics, but I don't especially want to invent further than that.

regards, tom lane

In response to


Browse pgsql-hackers by date

  From Date Subject
Next Message Daniel Verite 2017-01-24 18:08:08 Re: \if, \elseif, \else, \endif (was Re: PSQL commands: \quit_if, \quit_unless)
Previous Message Tobias Oberstein 2017-01-24 17:57:47 Re: lseek/read/write overhead becomes visible at scale ..