Re: plpgsql.consistent_into

From: Marti Raudsepp <marti(at)juffo(dot)org>
To: Marko Tiikkaja <marko(at)joh(dot)to>
Cc: PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: plpgsql.consistent_into
Date: 2014-01-14 01:54:48
Message-ID: CABRT9RByLAAg77NGrtvGx39s7k=4HG11-yc_qxz5v=oDtUp_Tg@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Sun, Jan 12, 2014 at 7:51 AM, Marko Tiikkaja <marko(at)joh(dot)to> wrote:
> the behaviour of SELECT .. INTO when the query returns more than one row.
> Some of you might know that no exception is raised in this case

Agreed. But I also agree with the rest of the thread about changing
current INTO behavior and introducing new GUC variables.

But PL/pgSQL already has an assignment syntax with the behavior you want:

DECLARE
foo int;
BEGIN
foo = generate_series(1,1); -- this is OK
foo = generate_series(1,2); -- fails
foo = 10 WHERE FALSE; -- sets foo to NULL
-- And you can actually do:
foo = some_col FROM some_table WHERE bar=10;
END;

So if we extend this syntax to support multiple columns, it should
satisfy the use cases you care about.

foo, bar = col1, col2 FROM some_table WHERE bar=10;

It's ugly without the explicit SELECT though. Perhaps make the SELECT optional:

foo, bar = SELECT col1, col2 FROM some_table WHERE bar=10;

I think that's more aesthetically pleasing than INTO and also looks
more familiar to other languages.

Plus, now you can copy-paste the query straight to an SQL shell
without another footgun involving creating new tables in your
database.

Regards,
Marti

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Josh Berkus 2014-01-14 01:56:05 Re: Linux kernel impact on PostgreSQL performance
Previous Message Andres Freund 2014-01-14 01:48:57 Re: Linux kernel impact on PostgreSQL performance