Date: Fri, 15 Jul 2016 07:13:33 +0200 (CEST)
From: Fabien COELHO <coelho@cri.ensmp.fr>
To: Tom Lane <tgl@sss.pgh.pa.us>
cc: Robert Haas <robertmhaas@gmail.com>,
        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: <32184.1468440143@sss.pgh.pa.us>
Message-ID: <alpine.DEB.2.20.1607150617550.25883@sto>
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>
 <32184.1468440143@sss.pgh.pa.us>
User-Agent: Alpine 2.20 (DEB 67 2015-01-07)
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII; format=flowed
Precedence: bulk
Sender: pgsql-hackers-owner@postgresql.org


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.


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