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

Re: BUG #4516: FOUND variable does not work after RETURN QUERY

From: Andrew Gierth <andrew(at)tao11(dot)riddles(dot)org(dot)uk>
To: pgsql-bugs(at)postgresql(dot)org
Subject: Re: BUG #4516: FOUND variable does not work after RETURN QUERY
Date: 2008-11-10 10:13:03
Message-ID: (view raw, whole thread or download thread mbox)
Lists: pgsql-bugspgsql-hackers
>>>>> "Pavel" == "Pavel Stehule" <pavel(dot)stehule(at)gmail(dot)com> writes:

 >> Well, changing the semantics of an already-released statement
 >> carries a risk of breaking existing apps that aren't expecting it
 >> to change FOUND.  So I'd want to see a pretty strong case why this
 >> is important --- not just that it didn't meet someone's
 >> didn't-read-the-manual expectation.

 Pavel> It's should do some problems, but I belive much less than
 Pavel> change of casting or tsearch2 integration. And actually it's
 Pavel> not ortogonal.  Every not dynamic statement change FOUND
 Pavel> variable.

Regardless of what you think of FOUND, a more serious problem is this:

postgres=# create function test(n integer) returns setof integer language plpgsql
  as $f$
      rc bigint;
      return query (select i from generate_series(1,n) i);
      get diagnostics rc = row_count;
      raise notice 'rc = %',rc;
postgres=# select test(3);
NOTICE:  rc = 0
(3 rows)

Since GET DIAGNOSTICS is documented as working for every SQL query
executed in the function, rather than for a specific list of
constructs, this is clearly a bug.

Andrew (irc:RhodiumToad)

In response to


pgsql-hackers by date

Next:From: KaiGai KoheiDate: 2008-11-10 10:21:38
Subject: Updates of SE-PostgreSQL 8.4devel patches (r1206)
Previous:From: Fujii MasaoDate: 2008-11-10 09:45:27
Subject: Re: Synchronous replication patch v1

pgsql-bugs by date

Next:From: Zdenek KotalaDate: 2008-11-10 12:31:50
Subject: Re: BUG #4494: Memory leak in pg_regress.c
Previous:From: Bruce MomjianDate: 2008-11-07 23:21:53
Subject: Re: Re: [BUGS] libpq does not manage SSL callbacks properly when other libraries are involved.

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