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

Re: PL/pgSQL: SELECT INTO EXACT

From: Matt Miller <mattm(at)epx(dot)com>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: pgsql-patches <pgsql-patches(at)postgresql(dot)org>
Subject: Re: PL/pgSQL: SELECT INTO EXACT
Date: 2005-07-29 22:43:13
Message-ID: 1122676993.7396.32.camel@dbamm01-linux (view raw or flat)
Thread:
Lists: pgsql-hackerspgsql-patches
On Fri, 2005-07-29 at 17:52 -0400, Tom Lane wrote:
> Matt Miller <mattm(at)epx(dot)com> writes:
> > The motivation is to come closer to Oracle's SELECT INTO
> > behavior: when SELECTing INTO scalar targets,
> > raise an exception and leave the targets untouched if the query does
> > not return exactly one row.  This patch does not go so far as
> > to raise an exception

> Uh, what's the point of being only sort-of compatible?  Why not throw
> the exception?

I guess my hesitation is that the PL/SQL notion of the exception as a
program flow control technique is a bit at odds with the PL/pgSQL notion
of the exception as a transaction control mechanism.  Maybe these
notions could be reconciled by a new NOSAVE option to the EXCEPTION
block definition, to suppress the savepoint and the exception-induced
rollback for that BEGIN ... END block.  Then an automatically-thrown
exception would not be so expensive.

> I dislike the choice of "EXACT", too, as it (a) adds a new
> reserved word and (b) doesn't seem to convey quite what is
> happening anyway

The motivation is that EXACTly one row must be returned.

Maybe UNIQUE instead of EXACT?

In response to

pgsql-hackers by date

Next:From: Matt MillerDate: 2005-07-29 22:47:18
Subject: Re: PL/pgSQL: SELECT INTO EXACT
Previous:From: Mark WongDate: 2005-07-29 22:26:36
Subject: Re: [Testperf-general] dbt2 & opteron performance

pgsql-patches by date

Next:From: Matt MillerDate: 2005-07-29 22:47:18
Subject: Re: PL/pgSQL: SELECT INTO EXACT
Previous:From: Alvaro HerreraDate: 2005-07-29 22:06:18
Subject: Re: [HACKERS] Autovacuum loose ends

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