Re: pgbench - allow to store select results into variables

From: Fabien COELHO <coelho(at)cri(dot)ensmp(dot)fr>
To: Tatsuo Ishii <ishii(at)sraoss(dot)co(dot)jp>
Cc: tgl(at)sss(dot)pgh(dot)pa(dot)us, rafia(dot)sabih(at)enterprisedb(dot)com, michael(dot)paquier(at)gmail(dot)com, Langote_Amit_f8(at)lab(dot)ntt(dot)co(dot)jp, robertmhaas(at)gmail(dot)com, pavel(dot)stehule(at)gmail(dot)com, PostgreSQL Developers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: pgbench - allow to store select results into variables
Date: 2017-04-07 09:43:53
Message-ID: alpine.DEB.2.20.1704071142420.16675@lancre
Views: Raw Message | Whole Thread | Download mbox
Thread:
Lists: pgsql-hackers


>> If I understand correctly, the patch is moved because of the unrelated
>> issue that variables cannot be utf8 in pgbench, and it is a condition
>> to consider this patch that existing pgbench variables (set with \set)
>> can be utf8?
>
> I'm not sure if it is "unrelated" because the new feature relies on
> existing pgbench variable infrastructure.

Sure. I meant that the constraint on variable names exists before the
patch and the patch is not related to variable names, but the patch is
about variables, obviously.

As "psql" variables can be utf8 and that the same scanner is used, but the
variables values are not stritcly the same (they are typed in pgbench),
I'm wondering whether the effort should be do share more code/abstraction
between psql & pgbench or just adjust/replicate the needed small
functions/code excerpts.

--
Fabien.

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Etsuro Fujita 2017-04-07 10:05:31 Re: Declarative partitioning - another take
Previous Message Heikki Linnakangas 2017-04-07 09:08:44 Re: Letting the client choose the protocol to use during a SASL exchange