Skip site navigation (1) Skip section navigation (2)

Re: Make plpgsql throw error for SELECT ... INTO rowtypevar , ... ?

From: Robert Haas <robertmhaas(at)gmail(dot)com>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: pgsql-hackers(at)postgresql(dot)org
Subject: Re: Make plpgsql throw error for SELECT ... INTO rowtypevar , ... ?
Date: 2010-03-01 19:25:00
Message-ID: 603c8f071003011125o130119f2lad177333fcd09fe2@mail.gmail.com (view raw or flat)
Thread:
Lists: pgsql-hackers
On Mon, Mar 1, 2010 at 1:39 PM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> Anybody have an opinion about whether to try to improve the error
> response exhibited in bug #5352?
> http://archives.postgresql.org/message-id/201003010922.o219M9lk016559@wwwmaster.postgresql.org
>
> Currently, if the first variable named after INTO is a rowtype variable,
> we just stop parsing the INTO clause right there.  Bug #5352 is not the
> first case we've seen of people expecting to be able to write additional
> INTO targets after that.  While I'm not interested right now in trying
> to define or implement what it would mean to do that, it would be a
> pretty trivial change to look ahead for a comma, and if one is seen to
> throw an error along the line of "INTO can have only one target variable
> if the target is a row or record variable".
>
> It seems just barely possible that this could break functions that work
> now, in which the INTO clause is located just ahead of a comma that does
> actually belong to the surrounding SELECT's syntax.  However the user
> could always work around it by relocating the INTO clause to someplace
> else --- like say the places that we recommend putting INTO.
>
> Aside from giving a less confusing message, making this change would
> help to forestall future compatibility problems when and if we do
> generalize INTO to accept multiple targets in such cases.  If we've been
> throwing an error for that syntax for a release or three, it'll be much
> less likely to bite people in the rear when it suddenly starts doing
> something different.
>
> So I'm inclined to make the change, but only in HEAD --- if there is
> anyone whose function gets broken, they'd want to see that happen in
> a major release not a minor update.
>
> Comments?

It seems like a reasonable thing to do, I guess.  The whole idea that
INTO can be placed absolutely anywhere is really pretty strange, and
this is only chipping away at the edges of the weirdness.

portal=# create or replace function f() returns integer as $$declare x
record; begin select 1 into x + 1 as v; return x.v; end $$ language
plpgsql;
CREATE FUNCTION
portal=# select f();
 f
---
 2
(1 row)

...Robert

In response to

pgsql-hackers by date

Next:From: Greg StarkDate: 2010-03-01 19:32:24
Subject: Re: Re: Hot Standby query cancellation and Streaming Replication integration
Previous:From: Josh BerkusDate: 2010-03-01 19:21:48
Subject: Re: Re: Hot Standby query cancellation and Streaming Replication integration

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group