Re: [HACKERS] pgbench - allow to store select results into variables - Mailing list pgsql-hackers

From Alvaro Herrera
Subject Re: [HACKERS] pgbench - allow to store select results into variables
Date
Msg-id 201901031751.h7siijzvd3ve@alvherre.pgsql
Whole thread Raw
In response to Re: [HACKERS] pgbench - allow to store select results intovariables  (Fabien COELHO <coelho@cri.ensmp.fr>)
Responses Re: [HACKERS] pgbench - allow to store select results intovariables  (Fabien COELHO <coelho@cri.ensmp.fr>)
List pgsql-hackers
I revised this patch a bit.  Here's v25, where some finishing touches
are needed -- see below.  I think with these changes the patch would
become committable, at least for me.

I didn't like that you were adding an #include of psqlscan_int.h into
pgbench.c, when there's a specific comment in the header saying not to
do that, so I opted for adding a new accessor function on psqlscan.h.

I renamed some of your parameter additions.  I think the new names are
clearer, but they meant the +1's in your code are now in illogical
places.  (I moved some; probably not enough).  Please review/fix that.

I think "gset" is not a great name for the new struct member; please
find a better name.  I suggest "targetvar" but feel free to choose a
name that suits your taste.

There are two XXX comments.  One is about a function needing a comment
atop it.  The other is about realloc behavior.  To fix this one I would
add a new struct member indicating the allocated size of the array, then
growing exponentially instead of one at a time.  For most cases you can
probably get away with never reallocating beyond an initial allocation
of, say, 8 members.

In the docs, the [prefix] part needs to be explained in the \cset entry;
right now it's in \gset, which comes afterwards.  Let's move the
explanation up, and then in \gset say "prefix behaves as in \cset".

Thanks

-- 
Álvaro Herrera                https://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services

Attachment

pgsql-hackers by date:

Previous
From: Andrew Alsup
Date:
Subject: Re: SQL/JSON: functions
Next
From: Tom Lane
Date:
Subject: Re: Python versions (was Re: RHEL 8.0 build)