Обсуждение: LOAD not updating object in session

Hiya
    I have written a trigger in C, and during the course of this I
discovered that the LOAD command in psql wasn't updating the object when
I made a change and recompiled.

    As requested by Tom, here is an example of this behaviour.  I have just
added this as a function as it performs the same.

here is my code:

--START--
#include "postgres.h"
#include "executor/spi.h"       /* this is what you need to work with
SPI */
#include "commands/trigger.h"   /* ... and triggers */

#include <stdio.h>

int main (int argc, char **argv)
{
    printf ("This is a trigger for PostgreSQL, not a standard
executable\n\n");

    return 0;
}

extern Datum trigf(PG_FUNCTION_ARGS);

PG_FUNCTION_INFO_V1(trigf);

Datum testtrig(PG_FUNCTION_ARGS)
{
  TriggerData *trigdata = (TriggerData *) fcinfo->context;

  elog(INFO,"This is a test trigger");

  //elog(INFO,"Uncomment me and recompile for new message");

return PointerGetDatum(NULL);
}
--END--

I have compiled and linked this with the lines:

gcc -g -c test_trigger.c  -I/usr/include/pgsql/server
gcc -o testtrigger test_trigger.o  --share

without errors.

to create the function I used:

create or replace function testtrig() RETURNS trigger AS
'/home/graeme/dev/radius-centraldb/testtrigger' LANGUAGE C;


Now when I "select testtrig();"  I get :

INFO:  This is a test trigger
ERROR:  Cannot display a value of type TRIGGER

If I uncomment out the 2nd elog line and recompile and then use

LOAD '/home/graeme/dev/radius-centraldb/testtrigger';

Again running "select testtrig()" I get :

INFO:  This is a test trigger
ERROR:  Cannot display a value of type TRIGGER

So the new Object hasn't been loaded (I know about the Error on the end,
this is just a quick test).

If I quit out of psql and reconned, and then run "select testtrig()" I
now get:

INFO:  This is a test trigger
INFO:  Uncomment me and recompile for new message
ERROR:  Cannot display a value of type TRIGGER


So as you can see it doesn't appear to be refreshing the C object when I
use LOAD.  I also noticed during writing the C for this example that if
I created the function with the wrong name I got an error saying that
that function could not be found in the object as is expected, if I then
renamed the function and recompiled the object, the create would give
the same error (obviously using the already linked object).  Load didn't
fix this either.

So am I doing something wrong? or have I found something?

Thanks for your help/time

--
-----
Graeme Hinchliffe (BSc)
Core Internet Systems Designer
Zen Internet (http://www.zen.co.uk/)

Direct: 0845 058 9074
Main  : 0845 058 9000
Fax   : 0845 058 9005

Graeme Hinchliffe <graeme.hinchliffe@zeninternet.co.uk> writes:
>     I have written a trigger in C, and during the course of this I
> discovered that the LOAD command in psql wasn't updating the object when
> I made a change and recompiled.
>     As requested by Tom, here is an example of this behaviour.  I have just
> added this as a function as it performs the same.

Thanks for the test case.  Unfortunately it works fine here:

regression=# select testtrig();
INFO:  This is a test trigger
ERROR:  cannot display a value of type trigger
regression=# LOAD '/home/tgl/testtrigger';
LOAD
regression=# select testtrig();
INFO:  This is a test trigger
INFO:  Uncomment me and recompile for new message
ERROR:  cannot display a value of type trigger
regression=#

This is on RHL 8.0 on i386.  What platform are you using exactly?

BTW, the file as given dumps core for me, because you have

> extern Datum trigf(PG_FUNCTION_ARGS);
> PG_FUNCTION_INFO_V1(trigf);
> Datum testtrig(PG_FUNCTION_ARGS)

and the V1 macro needs to reference testtrig not trigf.  However I do
not think this is related to the LOAD problem.

            regards, tom lane

On Tue, 2004-08-17 at 17:27, Tom Lane wrote:
> Graeme Hinchliffe <graeme.hinchliffe@zeninternet.co.uk> writes:
> >     I have written a trigger in C, and during the course of this I
> > discovered that the LOAD command in psql wasn't updating the object when
> > I made a change and recompiled.
> >     As requested by Tom, here is an example of this behaviour.  I have just
> > added this as a function as it performs the same.
>
> Thanks for the test case.  Unfortunately it works fine here:

damn :)  (but in a good way)


> This is on RHL 8.0 on i386.  What platform are you using exactly?

This is RH 9.0 on i386 from RPM's

> BTW, the file as given dumps core for me, because you have
>
> > extern Datum trigf(PG_FUNCTION_ARGS);
> > PG_FUNCTION_INFO_V1(trigf);
> > Datum testtrig(PG_FUNCTION_ARGS)

oops! In the original I did have my function named as trigf, but I
changed that so as not to conflict with the other function in my db

> and the V1 macro needs to reference testtrig not trigf.  However I do
> not think this is related to the LOAD problem.

It didn't dump core for me, it was quite happy :)  I would guess because
I have a function called trigf loaded in memory?

Do you have any ideas what I am doing or what I have set wrong?

--
-----
Graeme Hinchliffe (BSc)
Core Internet Systems Designer
Zen Internet (http://www.zen.co.uk/)

Direct: 0845 058 9074
Main  : 0845 058 9000
Fax   : 0845 058 9005

Graeme Hinchliffe <graeme.hinchliffe@zeninternet.co.uk> writes:
> It didn't dump core for me, it was quite happy :)  I would guess because
> I have a function called trigf loaded in memory?

No; the lack of a V1 macro referencing testtrig would definitely cause
the backend to call testtrig using V0 conventions, in other words fcinfo
will not be passed.  It could be that the indirection through a garbage
value of fcinfo happens to land on valid memory in your compilation.
(I did not get a core dump either when compiling on HPUX, but I have not
bothered to chase down why not.)

I don't know of any reason for RHL 9 to work differently from RHL 8 in
this regard.  Can anyone else duplicate the problem?

BTW, given the testtrig/trigf confusion ... is it possible you were
LOADing the wrong file?

            regards, tom lane