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

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).


Reply via email to