Re: Support for %TYPE in CREATE FUNCTION - Mailing list pgsql-hackers

From Don Baccus
Subject Re: Support for %TYPE in CREATE FUNCTION
Date
Msg-id 3.0.1.32.20010530104820.0181e870@mail.pacifier.com
Whole thread Raw
In response to Re: Support for %TYPE in CREATE FUNCTION  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: Support for %TYPE in CREATE FUNCTION  (Ian Lance Taylor <ian@airs.com>)
List pgsql-hackers
At 12:30 PM 5/30/01 -0400, Tom Lane wrote:
>Bruce Momjian <pgman@candle.pha.pa.us> writes:
>> I think the major problem was that our pg_proc table doesn't have any
>> way of handling arg changes.  In fact, we need a ALTER FUNCTION
>> capability first so we can recreate functions in place with the same
>> OID.
>
>Actually that's the least of the issues.  The real problem is that
>because of function overloading, myfunc(int4) and myfunc(int2) (for
>example) are considered completely different functions.  It is thus
>not at all clear what should happen if I create myfunc(foo.f1%TYPE)
>and later alter the type of foo.f1 from int4 to int2.  Does myfunc(int4)
>stop existing?

What happens now with PL/pgSQL variables?  Does it continue to point
int4 as long as the backend stays alive, but switch in new backends
as they come to life, the function gets called, and the body recompiled?

(Compiled bytes are stored on a per-backend basis, right?  Or wrong? :)

That's not particularly relevant to the parameter case other than to
point out that we may already have some weirdness in PL/pgSQL in
this regard.



- Don Baccus, Portland OR <dhogaza@pacifier.com> Nature photos, on-line guides, Pacific Northwest Rare Bird Alert
Serviceand other goodies at http://donb.photo.net.
 


pgsql-hackers by date:

Previous
From: The Hermit Hacker
Date:
Subject: intelligence in writing a query ...
Next
From: Ian Lance Taylor
Date:
Subject: Re: Support for %TYPE in CREATE FUNCTION