If I use CREATE FUNCTION for a C function in a .so file and then use the
function and then change and recompile the function, what steps are needed
to see the change?

As I see it the options are:
A: do nothing, the function is reloaded on every invocation.
B: Reopen the connection to the backend
C: Restart the postmaster

I suspect B is correct but I would like to hear someone confirm it.


Wed, 9 Feb 2000 16:31:14 -0500
"Bryan White" <bryan@arcamax.com>
The persistance of C functions

On 09-Feb-00 Bryan White wrote:
> If I use CREATE FUNCTION for a C function in a .so file and then use the
> function and then change and recompile the function, what steps are needed
> to see the change?
> 
> As I see it the options are:
> A: do nothing, the function is reloaded on every invocation.
> B: Reopen the connection to the backend
> C: Restart the postmaster
> 
> I suspect B is correct but I would like to hear someone confirm it.

        I don't know about A or B, but C definitely works :-). If it's
practical, I sometimes use DROP FUNCTION/CREATE FUNCTION, but I don't
think this is practical when you're using this function (or set of 
functions) to implement a new data type.

----------------------------------
Date: 09-Feb-00  Time: 14:16:54

Craig Orsinger                  (email: <orsingerc@epg-gw1.lewis.army.mil>)
Logicon RDA
Bldg. 8B28                      "Just another megalomaniac with ideas above his
6th & F Streets                 station. The Universe is full of them."
Ft. Lewis, WA   98433                   - The Doctor
----------------------------------

Wed, 09 Feb 2000 14:19:19 -0800 (PST)
Craig Orsinger <orsingerc@epg-gw1.lewis.army.mil>
RE: [INTERFACES] The persistance of C functions
> On 09-Feb-00 Bryan White wrote:
> > If I use CREATE FUNCTION for a C function in a .so file and then use the
> > function and then change and recompile the function, what steps are
needed
> > to see the change?
> >
> > As I see it the options are:
> > A: do nothing, the function is reloaded on every invocation.
> > B: Reopen the connection to the backend
> > C: Restart the postmaster
> >
> > I suspect B is correct but I would like to hear someone confirm it.
>
>         I don't know about A or B, but C definitely works :-). If it's
> practical, I sometimes use DROP FUNCTION/CREATE FUNCTION, but I don't
> think this is practical when you're using this function (or set of
> functions) to implement a new data type.

Thanks, I have come to the conclusion that B is sufficient based on trial
and error.



Wed, 9 Feb 2000 18:42:16 -0500
"Bryan White" <bryan@arcamax.com>
Re: [INTERFACES] The persistance of C functions

On Wed, 9 Feb 2000, Bryan White wrote:

> If I use CREATE FUNCTION for a C function in a .so file and then use the
> function and then change and recompile the function, what steps are needed
> to see the change?
> 
> As I see it the options are:
> A: do nothing, the function is reloaded on every invocation.
> B: Reopen the connection to the backend
> C: Restart the postmaster
> 
> I suspect B is correct but I would like to hear someone confirm it.


 'B' is right - the postgreSQL not has any persisten cache for this, and 
if you restart connection a backend reload this information again.

Or you can drop/(re)create a function, it is total safe solution.

							Karel


Thu, 10 Feb 2000 10:42:29 +0100 (CET)
Karel Zak - Zakkr <zakkr@zf.jcu.cz>
Re: [INTERFACES] The persistance of C functions
On Thu, Feb 10, 2000 at 10:42:29AM +0100, Karel Zak - Zakkr wrote:
> 
> On Wed, 9 Feb 2000, Bryan White wrote:
> 
> > If I use CREATE FUNCTION for a C function in a .so file and then use the
> > function and then change and recompile the function, what steps are needed
> > to see the change?
> > 
> > As I see it the options are:
> > A: do nothing, the function is reloaded on every invocation.
> > B: Reopen the connection to the backend
> > C: Restart the postmaster
> > 
> > I suspect B is correct but I would like to hear someone confirm it.
> 
> 
>  'B' is right - the postgreSQL not has any persisten cache for this, and 
> if you restart connection a backend reload this information again.
> 
> Or you can drop/(re)create a function, it is total safe solution.


Not _totally_ safe: if you've got anything that refers to that function,
like a user defined type definition, drop/(re)create will change the
function's oid in the pg_proc table, causing errors when the old
function is looked up. Hmm, an ALTER FUNCTION command might be nice...

Ross
-- 
Ross J. Reedstrom, Ph.D., <reedstrm@rice.edu> 
NSBRI Research Scientist/Programmer
Computer and Information Technology Institute
Rice University, 6100 S. Main St.,  Houston, TX 77005

Thu, 10 Feb 2000 10:34:50 -0600
"Ross J. Reedstrom" <reedstrm@wallace.ece.rice.edu>
Re: [INTERFACES] The persistance of C functions
Karel Zak - Zakkr wrote:

> > Not _totally_ safe: if you've got anything that refers to that function,
> > like a user defined type definition, drop/(re)create will change the
> > function's oid in the pg_proc table, causing errors when the old
> > function is looked up. Hmm, an ALTER FUNCTION command might be nice...
>
> ... and/or check dependencies on the function's oid if the function is DROP,
> (via FOREIGN KEYs ?). IMHO it is good item to TODO if really nothing check
> it.  (...resending to hackers)
>
>                                                         Karel

Yes. I think it would be an interesting discussion to see whether or not it would
be a good idea to integrate referential integrity with respect to the system
cataloge. The result *could* be backend code which is far easier to maintain, and
(with updateable oids), support for ALTER/DROP code which yields sane results. For
example, with the little COMMENT code, I had to find the backend code responsible
for dropping each of the associated object types - relations, aggregates, types,
functions, etc. in order to also drop the associated COMMENT. *AND *I also had to
find those areas where an object might be implicitly dropped by dropping another
object by calling a different routine -- for example, DROP TRIGGER calls a
different routine (DropTrigger) than what is called by the DROP TABLE code to drop
all triggers associated with it (RelationRemoveTriggers). With RI, a cascading
delete from pg_class could automatically drop the associated indexes, triggers,
comments, etc. And perhaps another trigger on pg_class should be used to remove the
actual relation file itself. Then one would only need to determine whether the DROP
should be allowed (if, for instance, it is a base class of an inheritence
hierarchy) or it should be rejected by the RI code. Likewise, the ALTER code could
perform a cascading update of oid (if necessary), to aide pg_dump when dumping
objects in oid order (TODO) to reduce the possibility of breaking a dependency...

Just some thoughts,

Mike Mascari






Fri, 11 Feb 2000 02:11:25 -0500
Mike Mascari <mascarm@mascari.com>
Re: [HACKERS] Re: [INTERFACES] The persistance of C functions

On Thu, 10 Feb 2000, Ross J. Reedstrom wrote:

> On Thu, Feb 10, 2000 at 10:42:29AM +0100, Karel Zak - Zakkr wrote:
> > 
> > On Wed, 9 Feb 2000, Bryan White wrote:
> > 
> > > If I use CREATE FUNCTION for a C function in a .so file and then use the
> > > function and then change and recompile the function, what steps are needed
> > > to see the change?
> > > 
> > > As I see it the options are:
> > > A: do nothing, the function is reloaded on every invocation.
> > > B: Reopen the connection to the backend
> > > C: Restart the postmaster
> > > 
> > > I suspect B is correct but I would like to hear someone confirm it.
> > 
> >  'B' is right - the postgreSQL not has any persisten cache for this, and 
> > if you restart connection a backend reload this information again.
> > 
> > Or you can drop/(re)create a function, it is total safe solution.
>
> Not _totally_ safe: if you've got anything that refers to that function,
> like a user defined type definition, drop/(re)create will change the
> function's oid in the pg_proc table, causing errors when the old
> function is looked up. Hmm, an ALTER FUNCTION command might be nice...

... and/or check dependencies on the function's oid if the function is DROP, 
(via FOREIGN KEYs ?). IMHO it is good item to TODO if really nothing check
it.  (...resending to hackers)

							Karel

 


Fri, 11 Feb 2000 11:34:52 +0100 (CET)
Karel Zak - Zakkr <zakkr@zf.jcu.cz>
Re: [INTERFACES] The persistance of C functions