[HACKERS] Bug in prepared statement cache invalidation? - Mailing list pgsql-hackers

From Konstantin Knizhnik
Subject [HACKERS] Bug in prepared statement cache invalidation?
Date
Msg-id 25dba024-9850-1dc1-bb18-1a82a6dd2c33@postgrespro.ru
Whole thread Raw
Responses Re: [HACKERS] Bug in prepared statement cache invalidation?  (Robert Haas <robertmhaas@gmail.com>)
List pgsql-hackers
Hi hackers,

I find out that now Postgres correctly invalidates prepared plans which 
directly depend on altered relation, but doesn't invalidate plans having 
transitive (indirect) dependencies.
Is it a bug or feature?

postgres=# create table foo(x integer);
CREATE TABLE
postgres=# select * from foo; x
---
(0 rows)

postgres=# create function returnqueryf()returns setof foo  as $$ begin 
return query select * from foo; end; $$ language plpgsql;
CREATE FUNCTION
postgres=# select * from returnqueryf(); x
---
(0 rows)

postgres=# create function returnqueryff()returns setof foo  as $$ begin 
return query select * from returnqueryf(); end; $$ language plpgsql;
CREATE FUNCTION
postgres=# select * from returnqueryff(); x
---
(0 rows)

postgres=# alter table foo add column y integer;
ALTER TABLE
postgres=# select * from foo; x | y
---+---
(0 rows)

postgres=# select * from returnqueryf(); x | y
---+---
(0 rows)

postgres=# select * from returnqueryff();
ERROR:  structure of query does not match function result type
DETAIL:  Number of returned columns (1) does not match expected column 
count (2).
CONTEXT:  PL/pgSQL function returnqueryff() line 1 at RETURN QUERY
p

-- 
Konstantin Knizhnik
Postgres Professional: http://www.postgrespro.com
The Russian Postgres Company




pgsql-hackers by date:

Previous
From: Andrew Borodin
Date:
Subject: Re: [HACKERS] Merge join for GiST
Next
From: Antonin Houska
Date:
Subject: Re: [HACKERS] Partition-wise aggregation/grouping