From: Tom Lane <tgl@sss.pgh.pa.us>
To: Robert Haas <robertmhaas@gmail.com>
cc: Fabien COELHO <coelho@cri.ensmp.fr>,
        Pavel Stehule <pavel.stehule@gmail.com>,
        PostgreSQL Developers <pgsql-hackers@postgresql.org>
Subject: Re: pgbench - allow to store select results into variables
In-reply-to: 
 <CA+TgmoaFOUVh5E5qbMjV6L6ub1NFML7U+4Cx+8CvLQgRPrO4Ng@mail.gmail.com>
References: <alpine.DEB.2.20.1607091005330.3412@sto>
 <CAFj8pRAgU0OzGM7Vqpf2KUR0KP2YNhtG54ji06W5StGmwyQKnA@mail.gmail.com>
 <alpine.DEB.2.20.1607091057300.3412@sto>
 <CAFj8pRBGrdiroRyJgCjtOmOrHCQu0L8KDGLU5czD2q+jF8bUxQ@mail.gmail.com>
 <alpine.DEB.2.20.1607091441480.3412@sto>
 <CA+TgmoaFOUVh5E5qbMjV6L6ub1NFML7U+4Cx+8CvLQgRPrO4Ng@mail.gmail.com>
Comments: In-reply-to Robert Haas <robertmhaas@gmail.com>
	message dated "Wed, 13 Jul 2016 14:34:24 -0500"
Date: Wed, 13 Jul 2016 16:02:23 -0400
Message-ID: <32184.1468440143@sss.pgh.pa.us>
Precedence: bulk
Sender: pgsql-hackers-owner@postgresql.org

Robert Haas <robertmhaas@gmail.com> writes:
> On Sat, Jul 9, 2016 at 7:52 AM, Fabien COELHO <coelho@cri.ensmp.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


-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers