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 |
Message-ID: | 23287.1485280696@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
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)
> 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
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 .. |