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

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

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: pgsql-hackers(at)postgreSQL(dot)org
Subject: Make plpgsql throw error for SELECT ... INTO rowtypevar , ... ?
Date: 2010-03-01 18:39:01
Message-ID: 21116.1267468741@sss.pgh.pa.us (view raw or flat)
Thread:
Lists: pgsql-hackers
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?

			regards, tom lane

Responses

pgsql-hackers by date

Next:From: Greg StarkDate: 2010-03-01 18:46:29
Subject: Re: Hot Standby query cancellation and Streaming Replication integration
Previous:From: Andrew DunstanDate: 2010-03-01 18:35:19
Subject: Re: Re: pgsql: add EPERM to the list of return codes to expect from opening

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