Re: pgbench - allow to store select results into variables

From: Tatsuo Ishii <ishii(at)sraoss(dot)co(dot)jp>
To: coelho(at)cri(dot)ensmp(dot)fr
Cc: ishii(at)sraoss(dot)co(dot)jp, rafia(dot)sabih(at)enterprisedb(dot)com, michael(dot)paquier(at)gmail(dot)com, tgl(at)sss(dot)pgh(dot)pa(dot)us, Langote_Amit_f8(at)lab(dot)ntt(dot)co(dot)jp, robertmhaas(at)gmail(dot)com, pavel(dot)stehule(at)gmail(dot)com, pgsql-hackers(at)postgresql(dot)org
Subject: Re: pgbench - allow to store select results into variables
Date: 2017-04-06 00:07:10
Views: Raw Message | Whole Thread | Download mbox | Resend email
Lists: pgsql-hackers

Tom and others,

I still wonder whether I should commit this or not because this patch
does not allow none ascii column names. We know pgbench variable name
has been restricted since the functionality was born. When users
explicitly define a pgbench variable using \set, it is not a too
strong limitation, because it's in a "pgbench world" anyway and
nothing is related to PostgreSQL core specs. However, \gset is not
happy with perfectly valid column names in PostgreSQL core, which
looks too inconsistent and confusing for users.

So the choices are:

1) commit the patch now with documenting the limitation.
(the patch looks good to me except the issue above)

2) move it to next cf hoping that someone starts the implementation to
eliminate the limitation of none ascii variable names.


Best regards,
Tatsuo Ishii
SRA OSS, Inc. Japan

> Hello Tatsuo-san,
>> It seems the new feature \gset doesn't work with tables having none
>> ascii column names:
> Indeed. The same error is triggered with the \set syntax, which does
> not involve any query execution.
> I have added a sentence mentionning the restriction when variables are
> first discussed in the documentation, see attached patch.
> --
> Fabien.

In response to


Browse pgsql-hackers by date

  From Date Subject
Next Message Neha Khatri 2017-04-06 00:17:17 Re: strange parallel query behavior after OOM crashes
Previous Message Andres Freund 2017-04-05 23:47:06 Re: Fast Default WIP patch for discussion