Re: pgbench more operators & functions

Tom Lane <tgl@sss.pgh.pa.us>

From: Tom Lane <tgl@sss.pgh.pa.us>
To: Robert Haas <robertmhaas@gmail.com>
Cc: Fabien COELHO <coelho@cri.ensmp.fr>, Haribabu Kommi <kommi.haribabu@gmail.com>, Amit Kapila <amit.kapila16@gmail.com>, Stephen Frost <sfrost@snowman.net>, Jeevan Ladhe <jeevan.ladhe@enterprisedb.com>, PostgreSQL Developers <pgsql-hackers@postgresql.org>
Date: 2017-01-24T17:58:16Z
Lists: pgsql-hackers
Robert Haas <robertmhaas@gmail.com> writes:
>> On Fri, Dec 2, 2016 at 1:28 AM, Fabien COELHO <coelho@cri.ensmp.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)
> https://www.postgresql.org/message-id/CA+Tgmoa0zp4A+S+KosaV4QfDz-wA56vLpH8me86rmpsnkvWc2w@mail.gmail.com

> 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


Commits

  1. Improve scripting language in pgbench