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

> -----Original Message-----
> From: Jan Wieck [mailto:janwieck(at)yahoo(dot)com]
> Sent: 11 February 2002 19:36
> To: jm(dot)poure(at)freesurf(dot)fr
> Cc: Andrew Sullivan; PostgreSQL general list;
> pgsql-hackers(at)postgresql(dot)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