From: | Pavel Stehule <pavel(dot)stehule(at)gmail(dot)com> |
---|---|
To: | Fabien COELHO <coelho(at)cri(dot)ensmp(dot)fr> |
Cc: | PostgreSQL Developers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: pgbench - allow to store select results into variables |
Date: | 2016-07-09 12:19:29 |
Message-ID: | CAFj8pRBGrdiroRyJgCjtOmOrHCQu0L8KDGLU5czD2q+jF8bUxQ@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
2016-07-09 11:19 GMT+02:00 Fabien COELHO <coelho(at)cri(dot)ensmp(dot)fr>:
>
> Hello Pavel,
>
> Why you are introducing \into and not \gset like psql does?
>>
>
> Good question.
>
> The \into syntax I implemented is more generic, you can send a bunch of
> queries together and extract the results, which makes sense from a client
> perspective where reducing latency is important:
>
> SELECT 1, 2 \; SELECT 3;
> \into one two three
>
I understand, but it looks little bit scary - but the argument of reducing
latency can be valid
>
> However "gset" only works on the last SELECT and if all columns have a
> name. This feature probably makes sense interactively, but for a script it
> seems more useful to allow batch processing and collect results afterwards.
>
> Also a more subjective argument: I do not like the gset automagic naming
> feature. I got more inspired by PL/pgSQL and ECPG which both have an "into"
> syntax with explicit variable names that let nothing to guessing. I like
> things to be simple and explicit, hence the proposed into.
>
the gset was originally designed differently - but now it is here - and it
is not practical to have two different, but pretty similar statements in
psql and pgbench.
Regards
Pavel
>
> --
> Fabien.
>
From | Date | Subject | |
---|---|---|---|
Next Message | Fabien COELHO | 2016-07-09 12:52:51 | Re: pgbench - allow to store select results into variables |
Previous Message | Fabien COELHO | 2016-07-09 09:19:15 | Re: pgbench - allow to store select results into variables |