Re: pgbench - add \aset to store results of a combined query - Mailing list pgsql-hackers

From Fabien COELHO
Subject Re: pgbench - add \aset to store results of a combined query
Date
Msg-id alpine.DEB.2.21.2004020729120.16227@pseudo
Whole thread Raw
In response to Re: pgbench - add \aset to store results of a combined query  (Michael Paquier <michael@paquier.xyz>)
Responses Re: pgbench - add \aset to store results of a combined query  (Michael Paquier <michael@paquier.xyz>)
List pgsql-hackers
Bonjour Michaël,

>> Except for the addition of a test case to skip empty results when
>> \aset is used, I think that we are pretty good here.
>
> While hacking on the patch more by myself, I found that mixing tests
> for \gset and \aset was rather messy.  A test for an empty result
> leads also to a failure with the pgbench command as we want to make
> sure that the variable does not exist in this case using debug().

ISTM that I submitted a patch to test whether a variable exists in 
pgbench, like available in psql (:{?var} I think), but AFAICS it did not 
pass. Maybe I should resurect it as it would allow to test simply whether 
an empty result was returned to aset, which could make sense in a bench 
script (get something, if it does not exist skip remainder… I can see some 
interesting use cases).

> So let's split the tests in three parts:
> - the set for \get is left alone.
> - addition of a new set for the valid cases of \aset.
> - addition of an invalid test for \aset (the empty set one).

Ok.

> Fabien, what do you think about the attached?

It does not need to create an UNLOGGED table, a mere "WHERE FALSE" 
suffices.

I do not understand why you removed the comment about meta which makes it 
false, so I added something minimal back.

> Perhaps we should also have a test where we return more than 1 row for 
> \get?  The last point is unrelated to this thread though.

Yes, but ISTM that it is not worth a dedicated patch… so I added a test 
similar to the one about empty aset.

See v7 attached.

-- 
Fabien.
Attachment

pgsql-hackers by date:

Previous
From: Amit Kapila
Date:
Subject: Re: User Interface for WAL usage data
Next
From: David Rowley
Date:
Subject: Re: Berserk Autovacuum (let's save next Mandrill)