Re: [GENERAL] Feature enhancement request : use of libg
От | Dave Page |
---|---|
Тема | Re: [GENERAL] Feature enhancement request : use of libg |
Дата | |
Msg-id | FED2B709E3270E4B903EB0175A49BCB104755D@dogbert.vale-housing.co.uk обсуждение исходный текст |
Список | pgsql-hackers |
> -----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
В списке pgsql-hackers по дате отправления: