Re: pgbench - allow to store select results into variables
От | Tom Lane |
---|---|
Тема | Re: pgbench - allow to store select results into variables |
Дата | |
Msg-id | 32184.1468440143@sss.pgh.pa.us обсуждение исходный текст |
Ответ на | Re: pgbench - allow to store select results into variables (Robert Haas <robertmhaas@gmail.com>) |
Ответы |
Re: pgbench - allow to store select results into variables
(Robert Haas <robertmhaas@gmail.com>)
Re: pgbench - allow to store select results into variables ("David G. Johnston" <david.g.johnston@gmail.com>) Re: pgbench - allow to store select results into variables (Fabien COELHO <coelho@cri.ensmp.fr>) Re: pgbench - allow to store select results into variables (Fabien COELHO <coelho@cri.ensmp.fr>) Re: pgbench - allow to store select results into variables (Fabien COELHO <coelho@cri.ensmp.fr>) |
Список | pgsql-hackers |
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
В списке pgsql-hackers по дате отправления: