|From:||Fabien COELHO <coelho(at)cri(dot)ensmp(dot)fr>|
|To:||Michael Paquier <michael(dot)paquier(at)gmail(dot)com>|
|Cc:||PostgreSQL Developers <pgsql-hackers(at)postgresql(dot)org>|
|Subject:||Re: extend pgbench expressions with functions|
|Views:||Raw Message | Whole Thread | Download mbox | Resend email|
>> ISTM that if pgbench is to be stopped, the simplest option is just to abort
>> with a nicer error message from the get*Rand function, there is no need to
>> change the function signature and transfer the error management upwards.
> That's fine to me, as long as the solution is elegant.
Hmmm, this is subjective:-)
I've decided to stay with the current behavior (\setrandom), that is to
abort the current transaction on errors but not to abort pgbench itself.
The check is done before calling the functions, and I let an assert in the
functions just to be sure. It is going to loop on errors anyway, but this
is what it already does anyway.
>> Ok. I'm hesitating about removing the operator management, especially if I'm
>> told to put it back afterwards.
> I can understand that, things like that happen all the time here and
> that's not a straight-forward patch that we have here. I am sure that
> additional opinions here would be good to have before taking one
> decision or another. With the current statu-quo, let's just do what
> you think is best.
I let the operators alone and just adds functions management next to it.
I'll merge operators as functions only if it is a blocker.
I have assumed that your v4 is really v17, and this is v18...
|Next Message||Marko Tiikkaja||2016-01-13 13:30:43||Re: Fwd: [JDBC] Re: 9.4-1207 behaves differently with server side prepared statements compared to 9.2-1102|
|Previous Message||Marko Tiikkaja||2016-01-13 13:28:05||Re: Fwd: [JDBC] Re: 9.4-1207 behaves differently with server side prepared statements compared to 9.2-1102|