Bonjour Michaël,
Sure. I meant that the feature would make sense to write benchmark scripts
which would use aset and be able to act on the success or not of this aset,
not to resurrect it for a hidden coverage test.
This could always be discussed for v14. We'll see.
Or v15, or never, who
On Thu, Apr 02, 2020 at 03:58:50PM +0200, Fabien COELHO wrote:
> Sure. I meant that the feature would make sense to write benchmark scripts
> which would use aset and be able to act on the success or not of this aset,
> not to resurrect it for a hidden coverage test.
This could always be
Michaël,
ISTM that I submitted a patch to test whether a variable exists in pgbench,
like available in psql (:{?var} I think),
Not sure if improving the readability of the tests is a reason for
this patch. So I would suggest to just live with relying on debug()
for now to check that a
On Thu, Apr 02, 2020 at 08:08:08AM +0200, Fabien COELHO wrote:
> 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
>
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
On Mon, Mar 30, 2020 at 03:30:58PM +0900, Michael Paquier wrote:
> 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
On Thu, Mar 26, 2020 at 10:35:03PM +0100, Fabien COELHO wrote:
> Your point is to store the gset/aset status into the meta field, even if the
> command type is SQL. This is not done for gset, which relies on the non-null
> prefix, and breaks the assumption that meta is set to something only when
>
Bonjour Michaël,
[...] Still sounds strange to me to invent a new variable to this
structure if it is possible to track the exact same thing with an
existing part of a Command, or it would make sense to split Command into
two different structures with an extra structure used after the
On Fri, Nov 29, 2019 at 10:34:05AM +0100, Fabien COELHO wrote:
>> It seems to me that there is no point to have the variable aset in
>> Command because this structure includes already MetaCommand, so the
>> information is duplicated. [...] Perhaps I am missing something?
>
> Yep. ISTM that you
On Tue, Mar 24, 2020 at 11:04:45AM -0400, David Steele wrote:
> On 11/29/19 4:34 AM, Fabien COELHO wrote:
>> MetaCommand is not enough: we need varprefix, and then distinguishing
>> between aset and gset. Although this last point can be done with a
>> MetaCommand, ISTM that a bool is_aset is clear
On 11/29/19 4:34 AM, Fabien COELHO wrote:
It seems to me that there is no point to have the variable aset in
Command because this structure includes already MetaCommand, so the
information is duplicated. [...] Perhaps I am missing something?
Yep. ISTM that you are missing that aset is not
Michaël,
+ boolaset;
It seems to me that there is no point to have the variable aset in
Command because this structure includes already MetaCommand, so the
information is duplicated. [...] Perhaps I am missing something?
Yep. ISTM that you are missing that aset is not an
On Thu, Aug 15, 2019 at 06:30:13PM +, Ibrar Ahmed wrote:
> The following review has been posted through the commitfest application:
> make installcheck-world: tested, passed
> Implements feature: tested, passed
> Spec compliant: tested, passed
> Documentation:not
The following review has been posted through the commitfest application:
make installcheck-world: tested, passed
Implements feature: tested, passed
Spec compliant: tested, passed
Documentation:not tested
The patch passed my review, I have not reviewed the
On Wed, Jul 10, 2019 at 11:33 AM Fabien COELHO wrote:
>
> Hello Ibrar,
>
> >> SELECT 1 AS one \;
> >> SELECT 2 AS two UNION SELECT 2 \;
> >> SELECT 3 AS three \aset
> >>
> >> will set both "one" and "three", while "two" is not set because there
> were
> >> two rows. It is a kind of more
Hello Ibrar,
SELECT 1 AS one \;
SELECT 2 AS two UNION SELECT 2 \;
SELECT 3 AS three \aset
will set both "one" and "three", while "two" is not set because there were
two rows. It is a kind of more permissive \gset.
Are you sure two is not set :)?
SELECT 2 AS two UNION SELECT 2; -- only
> SELECT 1 AS one \;
> SELECT 2 AS two UNION SELECT 2 \;
> SELECT 3 AS three \aset
>
> will set both "one" and "three", while "two" is not set because there were
> two rows. It is a kind of more permissive \gset.
Are you sure two is not set :)?
SELECT 2 AS two UNION SELECT 2; -- only
V2 is a rebase.
A long time ago I submitted a pgbench \into command to store results of
queries into variables independently of the query being processed, which got
turn into \gset (;) and \cset (\;), which got committed, then \cset was
removed because it was not "up to standard", as it
Hello devs,
A long time ago I submitted a pgbench \into command to store results of
queries into variables independently of the query being processed, which
got turn into \gset (;) and \cset (\;), which got committed, then \cset
was removed because it was not "up to standard", as it could
19 matches
Mail list logo
