Re: cache in plpgsql
От | ivan |
---|---|
Тема | Re: cache in plpgsql |
Дата | |
Msg-id | Pine.LNX.4.56.0312311417500.20780@rex.anfa.pl обсуждение исходный текст |
Ответ на | Re: cache in plpgsql (Jan Wieck <JanWieck@Yahoo.com>) |
Ответы |
Re: cache in plpgsql
|
Список | pgsql-hackers |
why all backend can not using one cache, which would be always in real state ... or i can just clear only my cache, at first (if i know that this relation could has another oid) and then normal using relations ? or ... just turn off cache, because its strange to has possible using drop, create etc in function, but using only EXECUTE .. there must be same solution .. no ? On Wed, 31 Dec 2003, Jan Wieck wrote: > ivan wrote: > > >as new know plpgsql has special cache which remember too long (event > >non-existing tables (i mean old oid)) so i suggest to create same function > >only in plpgsql which would clear this cache, or sth like this ? > > > >for ie, where i drop table i would do plpgsql_clear_cache (); > >and when i will create one more time table with this same name plpgsql > >will not remeber wrong oid > > > >possible ? > > > > > > You obviously did not bother to search the archives on this. > > This will not solve the problem since the "cache" you're talking about > is per backend local memory. So if one backend modifies the schema, how > does it cause all other to forgt? Since the same problem exists in > general for everything that uses SPI, the solution lies in there. > > > Jan > > -- > > #======================================================================# > # It's easier to get forgiveness for being wrong than for being right. # > # Let's break this rule - forgive me. # > #================================================== JanWieck@Yahoo.com # > > > > > ---------------------------(end of broadcast)--------------------------- > TIP 3: if posting/reading through Usenet, please send an appropriate > subscribe-nomail command to majordomo@postgresql.org so that your > message can get through to the mailing list cleanly >
В списке pgsql-hackers по дате отправления: