Re: plan invalidation vs stored procedures - Mailing list pgsql-hackers

From Pavel Stehule
Subject Re: plan invalidation vs stored procedures
Date
Msg-id 162867790808050716o9f2a81ld8b09a1ef3cf9157@mail.gmail.com
Whole thread Raw
In response to Re: plan invalidation vs stored procedures  (Martin Pihlak <martin.pihlak@gmail.com>)
Responses Re: plan invalidation vs stored procedures  (Hannu Krosing <hannu@krosing.net>)
List pgsql-hackers
2008/8/5 Martin Pihlak <martin.pihlak@gmail.com>:
>>> DROP FUNCTION
>>> create function foo() returns integer as $$ begin return 2; end; $$ language plpgsql;
>>> CREATE FUNCTION
>>> execute c1;
>>> psql:test.sql:11: ERROR:  cache lookup failed for function 36555
>>
>> This is simply a bad, wrong, stupid way to do it.  Why do you not use
>> CREATE OR REPLACE FUNCTION?
>>
>
> Well, the test case was an illustration. The actual reason for DROP and CREATE is
> the inability to change function return type. In our case there are plpgsql OUT
> parameters involved, and there is no other way to add additional OUT parameters
> without dropping the function first. I'd be glad if this was fixed, but I still
> think that proper plan invalidation for function changes is needed (inlined
> functions, ALTER FUNCTION stuff etc.)

It isn't possible. Probably some wrong is in your database design.

regards
Pavel Stehule

>
> regards,
> Martin
>
>


pgsql-hackers by date:

Previous
From: Martin Pihlak
Date:
Subject: Re: plan invalidation vs stored procedures
Next
From: Tom Lane
Date:
Subject: Re: Parsing of pg_hba.conf and authentication inconsistencies