Re: pgbench - allow to store select results into variables
От | Fabien COELHO |
---|---|
Тема | Re: pgbench - allow to store select results into variables |
Дата | |
Msg-id | alpine.DEB.2.20.1607150617550.25883@sto обсуждение исходный текст |
Ответ на | Re: pgbench - allow to store select results into variables (Tom Lane <tgl@sss.pgh.pa.us>) |
Список | 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.
В списке pgsql-hackers по дате отправления: