Thread: Re: [GENERAL] Feature enhancement request : use of libg

Re: [GENERAL] Feature enhancement request : use of libg

From
Dave Page
Date:

> -----Original Message-----
> From: Jan Wieck [mailto:janwieck@yahoo.com]
> Sent: 11 February 2002 19:36
> To: jm.poure@freesurf.fr
> Cc: Andrew Sullivan; PostgreSQL general list;
> pgsql-hackers@postgresql.org
> Subject: Re: [GENERAL] [HACKERS] Feature enhancement request
> : use of libgda
>
>
> Jean-Michel POURE wrote:
> >
> > CREATE OR REPLACE VIEW / TRIGGER and ALTER TABLE DROP
> COLUMN are real
> > priorities for us at pgAdmin team
> (http://pgadmin.postgresql.org). I
> > don't know PostgreSQL internals, but it should take a few
> days/weeks
> > to an experienced hacker to add these features.
>
> Jean-Michel,
>
>     I think you underestimate the problem a little.
>
>     Doing  CREATE OR REPLACE is not that trivial as you appear to
>     think.  The existing PL handlers (for PL/Tcl and PL/pgSQL  at
>     least)   identify   functions  by  their  pg_proc  OID.   The
>     functions body text is parsed only on the first call to  that
>     function during the entire session. So changing the functions
>     prosrc attribute after having called it already wouldn't take
>     effect until the next "session". But changing the OID as well
>     corrupts existing SPI plans in other functions plus rules.
>
>     Now it might be possible to tell  your  function  handler  to
>     recompile that function at the next call without changing the
>     OID, but how do you tell the function  handlers  in  all  the
>     other  concurrently running backends to do so after finishing
>     their current transaction?

Bearing in mind that I know nearly nothing about internals here :), how
about storing a version number in pg_proc? CREATE OR REPLACE updates that,
and each backend notes it when first parsing the function. Future calls of
the function result in a check of the version, and re-parse if necessary.

I'm sure there's far more to this than I realise... :-)

Regards, Dave