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: | Whole Thread | Raw Message | 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
>
>
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 |