From: | Fabien COELHO <coelho(at)cri(dot)ensmp(dot)fr> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | Robert Haas <robertmhaas(at)gmail(dot)com>, Pavel Stehule <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: | 2016-07-15 05:13:33 |
Message-ID: | alpine.DEB.2.20.1607150617550.25883@sto |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Hello Tom,
> Yeah, that's seriously nasty action-at-a-distance in my view. I'd be okay
> with
>
> SELECT 1, 2 \into one two
> SELECT 3 \into three
After giving it some thoughts, it could work on compound commands if \into
does not close the current sql command. Something like:
SELECT 1, 2 ; \into one two
SELECT 3 ; \into three
=> 2 SQL commands
SELECT 1, 2 \; \into one two
SELECT 3 ; \into three
=> 1 compound SQL command
I'd like \; or ; to stay mandatory as separators, though. Or at least to
be allowed.
I'm not quite sure how it could be implemented, though.
> And I'm with Pavel on this: it should work exactly like \gset.
Hmmm. Maybe I'll do that thing in the end, but I really think than gset
only makes sense in interactive context, and is pretty ugly for scripting.
> Inventing \into to do almost the same thing in a randomly different way
> exhibits a bad case of NIH syndrome.
No, it is a question of design suitable to programming:
> SELECT 1, 2 \gset v
could not set variable "?column?"
> Sure, you can argue about how it's not quite the same use-case
Indeed, that is my point.
> and so you could micro-optimize by doing it differently,
No, the underlying implementation is basically the same.
> but that's ignoring the cognitive load on users who have to remember two
> different commands.
I do not buy this argument: It is easier for me to remember that keyword
INTO happens to do the same thing the same way in PL/pgSQL and ECPG,
although with slightly different syntaxes, than to have to remember
psql-specific "gset" which does the same thing but in quite a different
way, because it means both another name and another concept.
> Claiming that plpgsql's SELECT INTO is a closer analogy than psql's
> \gset is quite bogus, too:
I disagree. I mentionned ECPG as well. Both ECPG & PLpgSQL are
"programming", psql is interactive.
> the environment is different (client side vs server side,
ECPG is client side. I think that the side does not matter.
> declared vs undeclared target variables),
Sure, the "gset" hack is only possible for a language without variable
declarations... but that does not make it a good idea.
> and the syntax is different (backslash or not, commas or not, just for
> starters).
Sure, different languages do not have the same syntax.
--
Fabien.
From | Date | Subject | |
---|---|---|---|
Next Message | Ashutosh Bapat | 2016-07-15 05:13:57 | Re: Oddity in handling of cached plans for FDW queries |
Previous Message | Peter Geoghegan | 2016-07-15 04:00:38 | Re: Improving executor performance - tidbitmap |