Re: plan invalidation vs stored procedures

From: "Pavel Stehule" <pavel(dot)stehule(at)gmail(dot)com>
To: "Martin Pihlak" <martin(dot)pihlak(at)gmail(dot)com>
Cc: "Tom Lane" <tgl(at)sss(dot)pgh(dot)pa(dot)us>, "Pg Hackers" <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: plan invalidation vs stored procedures
Date: 2008-08-05 14:16:45
Message-ID: 162867790808050716o9f2a81ld8b09a1ef3cf9157@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

2008/8/5 Martin Pihlak <martin(dot)pihlak(at)gmail(dot)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
>
>

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2008-08-05 14:17:19 Re: Parsing of pg_hba.conf and authentication inconsistencies
Previous Message Martin Pihlak 2008-08-05 14:12:34 Re: plan invalidation vs stored procedures