Re: [HACKERS] pgbench - allow to store select results intovariables

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.