Hello Tom,

Yeah, that's seriously nasty action-at-a-distance in my view.  I'd be okay

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.


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

Reply via email to