From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Robert Haas <robertmhaas(at)gmail(dot)com> |
Cc: | Fabien COELHO <coelho(at)cri(dot)ensmp(dot)fr>, 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-13 20:02:23 |
Message-ID: | 32184.1468440143@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Robert Haas <robertmhaas(at)gmail(dot)com> writes:
> On Sat, Jul 9, 2016 at 7:52 AM, Fabien COELHO <coelho(at)cri(dot)ensmp(dot)fr> wrote:
>> If someone thinks that "gset" is a good idea for pgbench, which I don't, it
>> could be implemented. I think that an "into" feature, like PL/pgSQL & ECPG,
>> makes more sense for scripting.
> I agree: I like \into.
> But:
>> SELECT 1, 2 \; SELECT 3;
>> \into one two three
> I think that's pretty weird.
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
but I do not think that a metacommand on a following line should
retroactively affect the execution of a prior command, much less commands
before the last one. Even if this happens to be easy to do in pgbench's
existing over-contorted logic, it's tremendously confusing to the user;
and it might be much less easy if we try to refactor that logic.
And I'm with Pavel on this: it should work exactly like \gset. Inventing
\into to do almost the same thing in a randomly different way exhibits a
bad case of NIH syndrome. Sure, you can argue about how it's not quite
the same use-case and so you could micro-optimize by doing it differently,
but that's ignoring the cognitive load on users who have to remember two
different commands. Claiming that plpgsql's SELECT INTO is a closer
analogy than psql's \gset is quite bogus, too: the environment is
different (client side vs server side, declared vs undeclared target
variables), and the syntax is different (backslash or not, commas or not,
just for starters). I note also that we were talking a couple months ago
about trying to align psql and pgbench backslash commands more closely.
This would not be a good step in that direction.
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Robert Haas | 2016-07-13 20:03:49 | Re: remove checkpoint_warning |
Previous Message | Robert Haas | 2016-07-13 19:59:28 | Re: One process per session lack of sharing |