pg.ddx.io pgsql-interfaces@postgresql.org mailing list archive
help / color / mirror / Atom feedThe persistance of C functions
7+ messages / 5 participants
[nested] [flat]
* The persistance of C functions
@ 2000-02-09 21:31 Bryan White <bryan@arcamax.com>
0 siblings, 2 replies; 7+ messages in thread
From: Bryan White @ 2000-02-09 21:31 UTC (permalink / raw)
To: pgsql-interfaces
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.
^ permalink raw reply [nested|flat] 7+ messages in thread
* RE: [INTERFACES] The persistance of C functions
@ 2000-02-09 22:19 Craig Orsinger <orsingerc@epg-gw1.lewis.army.mil>
parent: Bryan White <bryan@arcamax.com>
1 sibling, 1 reply; 7+ messages in thread
From: Craig Orsinger @ 2000-02-09 22:19 UTC (permalink / raw)
To: pgsql-interfaces
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
----------------------------------
^ permalink raw reply [nested|flat] 7+ messages in thread
* Re: [INTERFACES] The persistance of C functions
@ 2000-02-09 23:42 Bryan White <bryan@arcamax.com>
parent: Craig Orsinger <orsingerc@epg-gw1.lewis.army.mil>
0 siblings, 0 replies; 7+ messages in thread
From: Bryan White @ 2000-02-09 23:42 UTC (permalink / raw)
To: pgsql-interfaces
> 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.
^ permalink raw reply [nested|flat] 7+ messages in thread
* Re: [INTERFACES] The persistance of C functions
@ 2000-02-10 09:42 Karel Zak - Zakkr <zakkr@zf.jcu.cz>
parent: Bryan White <bryan@arcamax.com>
1 sibling, 1 reply; 7+ messages in thread
From: Karel Zak - Zakkr @ 2000-02-10 09:42 UTC (permalink / raw)
To: Bryan White <bryan@arcamax.com>; +Cc: pgsql-interfaces
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
^ permalink raw reply [nested|flat] 7+ messages in thread
* Re: [INTERFACES] The persistance of C functions
@ 2000-02-10 16:34 Ross J. Reedstrom <reedstrm@wallace.ece.rice.edu>
parent: Karel Zak - Zakkr <zakkr@zf.jcu.cz>
0 siblings, 1 reply; 7+ messages in thread
From: Ross J. Reedstrom @ 2000-02-10 16:34 UTC (permalink / raw)
To: Karel Zak - Zakkr <zakkr@zf.jcu.cz>; +Cc: Bryan White <bryan@arcamax.com>; pgsql-interfaces
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
^ permalink raw reply [nested|flat] 7+ messages in thread
* Re: [HACKERS] Re: [INTERFACES] The persistance of C functions
@ 2000-02-11 07:11 Mike Mascari <mascarm@mascari.com>
parent: Karel Zak - Zakkr <zakkr@zf.jcu.cz>
0 siblings, 0 replies; 7+ messages in thread
From: Mike Mascari @ 2000-02-11 07:11 UTC (permalink / raw)
To: Karel Zak - Zakkr <zakkr@zf.jcu.cz>; +Cc: Ross J. Reedstrom <reedstrm@wallace.ece.rice.edu>; pgsql-hackers <pgsql-hackers@postgreSQL.org>; Bryan White <bryan@arcamax.com>
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
^ permalink raw reply [nested|flat] 7+ messages in thread
* Re: [INTERFACES] The persistance of C functions
@ 2000-02-11 10:34 Karel Zak - Zakkr <zakkr@zf.jcu.cz>
parent: Ross J. Reedstrom <reedstrm@wallace.ece.rice.edu>
0 siblings, 1 reply; 7+ messages in thread
From: Karel Zak - Zakkr @ 2000-02-11 10:34 UTC (permalink / raw)
To: Ross J. Reedstrom <reedstrm@wallace.ece.rice.edu>; +Cc: pgsql-hackers <pgsql-hackers@postgreSQL.org>; Bryan White <bryan@arcamax.com>
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
^ permalink raw reply [nested|flat] 7+ messages in thread
end of thread, other threads:[~2000-02-11 10:34 UTC | newest]
Thread overview: 7+ messages (download: mbox mbox.gz follow: Atom feed)
-- links below jump to the message on this page --
2000-02-09 21:31 The persistance of C functions Bryan White <bryan@arcamax.com>
2000-02-09 22:19 ` Craig Orsinger <orsingerc@epg-gw1.lewis.army.mil>
2000-02-09 23:42 ` Bryan White <bryan@arcamax.com>
2000-02-10 09:42 ` Karel Zak - Zakkr <zakkr@zf.jcu.cz>
2000-02-10 16:34 ` Ross J. Reedstrom <reedstrm@wallace.ece.rice.edu>
2000-02-11 10:34 ` Karel Zak - Zakkr <zakkr@zf.jcu.cz>
2000-02-11 07:11 ` Mike Mascari <mascarm@mascari.com>
This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox