Hello Stephen,
>>> Might be interesting to support mutli-row (or no row?) returns in the
>>> future, but not something this patch needs to do, so this looks fine to
>>> me.
>>
>> It could match PL/pgSQL's INTO, that is first row or NULL if none.
>
> Yeah, but that's not really something that needs to go into this patch.
Sure. I did not. I checked psql \gset behavior:
psql> SELECT 1 AS stuff WHERE false \gset
no rows returned for \gset
psql> \echo :stuff
:stuff -- "stuff" var was not set
psql> SELECT i AS stuff FROM generate_series(1,5) AS i \gset
more than one row returned for \gset
psql> \echo :stuff
:stuff -- "stuff" var was not set either
If the semantics is changed in anyway, ISTM that psql & pgbench should be
kept consistent.
>> If this patch get through, might be handy for simplifying tests in
>> current pgbench submissions, especially the "error handling" one.
>
> Glad to hear that. Unfortunately, I didn't end up having time to wrap
> this up to a satisfactory level for myself to get it into PG11.
No problem with waiting for PG<N+1>. Whatever N:-)
> I know it's been a long time coming, and thank you for continuing to
> push on it;
Yeah, I'm kind of stubborn. Sometimes a quality, often a flaw.
> I'll try to make sure that I take some time in the first CF
> for PG12 to wrap this up and get it in. I'm all for these improvements
> in pgbench in general, it's a really useful tool and it's great to see
> work going into it.
Thanks for scheduling a try! :-)
When it gets in, I'll submit, eventually, a "tpcb-strict" builtin
benchmarking script for illustration, which would implement the bench
requirement that clients more often query in their own branch. This would
take advantage of recently (PG11) added \if and logical expressions (for
correlating clients to their branch) and gset (the benchmark states that
the client must retrieve the value, whereas it is currently discarded).
--
Fabien.