On Wed, Aug 6, 2008 at 3:29 PM, Florian Pflug <[EMAIL PROTECTED]> wrote:
> Merlin Moncure wrote:
>>
>> you missed the point...if your return type is a composite type that is
>> backed by the table (CREATE TABLE, not CREATE TYPE), then you can
>> 'alter' the type by altering the table. This can be
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Hi,
Le 6 août 08 à 20:42, Marko Kreen a écrit :
But you missed my point: if you don't have functions backed by table,
the DROP+CREATE results in inappropriate behaviour that can be
avoided.
Just wanted to say I agree with Marko here: it seems w
On 8/6/08, Florian Pflug <[EMAIL PROTECTED]> wrote:
> Merlin Moncure wrote:
> > you missed the point...if your return type is a composite type that is
> > backed by the table (CREATE TABLE, not CREATE TYPE), then you can
> > 'alter' the type by altering the table. This can be done without full
> >
Merlin Moncure wrote:
you missed the point...if your return type is a composite type that is
backed by the table (CREATE TABLE, not CREATE TYPE), then you can
'alter' the type by altering the table. This can be done without full
drop recreate of the function.
Which - at least IMHO - clearly sh
On 8/6/08, Merlin Moncure <[EMAIL PROTECTED]> wrote:
> On Wed, Aug 6, 2008 at 2:28 PM, Marko Kreen <[EMAIL PROTECTED]> wrote:
> > On 8/6/08, Merlin Moncure <[EMAIL PROTECTED]> wrote:
> >> On Wed, Aug 6, 2008 at 2:20 AM, Marko Kreen <[EMAIL PROTECTED]> wrote:
> >> > But the main problem is that
Don't you think we try to be careful but still we manage to overlook several
times in year something and cause some stupid downtime.
On Wed, Aug 6, 2008 at 9:13 PM, Merlin Moncure <[EMAIL PROTECTED]> wrote:
> On Wed, Aug 6, 2008 at 2:20 AM, Marko Kreen <[EMAIL PROTECTED]> wrote:
> > But the main
On Wed, Aug 6, 2008 at 2:28 PM, Marko Kreen <[EMAIL PROTECTED]> wrote:
> On 8/6/08, Merlin Moncure <[EMAIL PROTECTED]> wrote:
>> On Wed, Aug 6, 2008 at 2:20 AM, Marko Kreen <[EMAIL PROTECTED]> wrote:
>> > But the main problem is that if the DROP/CREATE happens, the failure
>> > mode is very nasty
On 8/6/08, Merlin Moncure <[EMAIL PROTECTED]> wrote:
> On Wed, Aug 6, 2008 at 2:20 AM, Marko Kreen <[EMAIL PROTECTED]> wrote:
> > But the main problem is that if the DROP/CREATE happens, the failure
> > mode is very nasty - you get permanent error on existing backends.
> > (Main case I'm talking
On Wed, Aug 6, 2008 at 2:20 AM, Marko Kreen <[EMAIL PROTECTED]> wrote:
> But the main problem is that if the DROP/CREATE happens, the failure
> mode is very nasty - you get permanent error on existing backends.
> (Main case I'm talking about is functions calling other functions.)
>
> Some sorta rec
On Wed, 2008-08-06 at 15:41 +0200, Pavel Stehule wrote:
> 2008/8/6 Hannu Krosing <[EMAIL PROTECTED]>:
> > On Wed, 2008-08-06 at 12:13 +0200, Pavel Stehule wrote:
> >> 2008/8/6 Hannu Krosing <[EMAIL PROTECTED]>:
> >> > On Tue, 2008-08-05 at 16:17 +0200, Pavel Stehule wrote:
> > ..
> >> >> you cannot
2008/8/6 Hannu Krosing <[EMAIL PROTECTED]>:
> On Wed, 2008-08-06 at 12:13 +0200, Pavel Stehule wrote:
>> 2008/8/6 Hannu Krosing <[EMAIL PROTECTED]>:
>> > On Tue, 2008-08-05 at 16:17 +0200, Pavel Stehule wrote:
> ..
>> >> you cannot change header of function. It's same as change C header of
>> >> fu
On Wed, 2008-08-06 at 12:13 +0200, Pavel Stehule wrote:
> 2008/8/6 Hannu Krosing <[EMAIL PROTECTED]>:
> > On Tue, 2008-08-05 at 16:17 +0200, Pavel Stehule wrote:
..
> >> you cannot change header of function. It's same as change C header of
> >> function without complete recompilation.
> >
> > SQL i
2008/8/6 Hannu Krosing <[EMAIL PROTECTED]>:
> On Tue, 2008-08-05 at 16:17 +0200, Pavel Stehule wrote:
>> 2008/8/5 Asko Oja <[EMAIL PROTECTED]>:
>> > postgres=# create or replace function pavel ( i_param text, status OUT int,
>> > status_text OUT text ) returns record as $$ select 200::int, 'ok'::te
On Tue, 2008-08-05 at 16:17 +0200, Pavel Stehule wrote:
> 2008/8/5 Asko Oja <[EMAIL PROTECTED]>:
> > postgres=# create or replace function pavel ( i_param text, status OUT int,
> > status_text OUT text ) returns record as $$ select 200::int, 'ok'::text; $$
> > language sql;
> > CREATE FUNCTION
> >
On Tue, 2008-08-05 at 16:16 +0200, Pavel Stehule wrote:
> 2008/8/5 Martin Pihlak <[EMAIL PROTECTED]>:
> >>> DROP FUNCTION
> >>> create function foo() returns integer as $$ begin return 2; end; $$
> >>> language plpgsql;
> >>> CREATE FUNCTION
> >>> execute c1;
> >>> psql:test.sql:11: ERROR: cache
On 8/5/08, Merlin Moncure <[EMAIL PROTECTED]> wrote:
> On Tue, Aug 5, 2008 at 10:12 AM, Martin Pihlak <[EMAIL PROTECTED]> wrote:
> >>> DROP FUNCTION
> >>> create function foo() returns integer as $$ begin return 2; end; $$
> language plpgsql;
> >>> CREATE FUNCTION
> >>> execute c1;
> >>> psql
On Tue, Aug 5, 2008 at 10:12 AM, Martin Pihlak <[EMAIL PROTECTED]> wrote:
>>> 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
>>
>> T
On 8/5/08, Pavel Stehule <[EMAIL PROTECTED]> wrote:
> >> ERROR: cannot change return type of existing function
> >> HINT: Use DROP FUNCTION first.
>
> you cannot change header of function. It's same as change C header of
> function without complete recompilation.
Thats why plan invalidation fo
2008/8/5 Asko Oja <[EMAIL PROTECTED]>:
> postgres=# create or replace function pavel ( i_param text, status OUT int,
> status_text OUT text ) returns record as $$ select 200::int, 'ok'::text; $$
> language sql;
> CREATE FUNCTION
> postgres=# create or replace function pavel ( i_param text, status O
2008/8/5 Martin Pihlak <[EMAIL PROTECTED]>:
>>> 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, st
>> 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
postgres=# create or replace function pavel ( i_param text, status OUT int,
status_text OUT text ) returns record as $$ select 200::int, 'ok'::text; $$
language sql;
CREATE FUNCTION
postgres=# create or replace function pavel ( i_param text, status OUT int,
status_text OUT text, more_text OUT text
> This is simply a bad, wrong, stupid way to do it. Why do you not use
> CREATE OR REPLACE FUNCTION?
I totally agree we should get this fixed first :)
postgres=# create or replace function pavel ( i_param text, status OUT int,
status_text OUT text ) returns record as $$ select 200::int, 'ok'::tex
Martin Pihlak <[EMAIL PROTECTED]> writes:
> create function foo() returns integer as $$ begin return 1; end; $$ language
> plpgsql;
> CREATE FUNCTION
> prepare c1 as select * from foo();
> PREPARE
> execute c1;
> foo
> -
>1
> (1 row)
> drop function foo();
> DROP FUNCTION
> create functi
Hi
Thanks for pointing to another thing to fix :)
postgres=# create type public.ret_status as ( status integer, status_text
text);
CREATE TYPE
postgres=# create or replace function pavel ( i_param text ) returns
public.ret_status as $$ select 200::int, 'ok'::text; $$ language sql;
CREATE FUNCTION
2008/8/5 Martin Pihlak <[EMAIL PROTECTED]>:
> Pavel Stehule wrote:
>> Hello
>>
>> try version 8.3. There lot of dependencies are solved.
>>
>
> Yes, 8.3 was the version I was testing with. Same results on the HEAD:
>
> $ psql -e -f test.sql
> select version();
>
Hi
Sadly PostgreSQL inability to invalidate plan cache when function is dropped
causes us downtime and costs money.
ERROR: cache lookup failed for function 24865)
This time our developers just rewrote function to use OUT parameters instead
of return type.
Currently i had to forbid dropping functi
Pavel Stehule wrote:
> Hello
>
> try version 8.3. There lot of dependencies are solved.
>
Yes, 8.3 was the version I was testing with. Same results on the HEAD:
$ psql -e -f test.sql
select version();
version
Hello
try version 8.3. There lot of dependencies are solved.
Regards
Pavel Stehule
2008/8/5 Martin Pihlak <[EMAIL PROTECTED]>:
> Howdy,
>
> What is the status of plan invalidation vs stored procedures? From
> the initial design discussion I understand that function change handling
> was postpone
Howdy,
What is the status of plan invalidation vs stored procedures? From
the initial design discussion I understand that function change handling
was postponed to "some time in the future". Is anybody already working
on that or maybe some ideas of how to implement this?
The business case for the
30 matches
Mail list logo
