Re: Discontent with development process (was:Re: pgaccess
От | Marc G. Fournier |
---|---|
Тема | Re: Discontent with development process (was:Re: pgaccess |
Дата | |
Msg-id | 20020515004347.R75064-100000@mail1.hub.org обсуждение исходный текст |
Ответ на | Re: Discontent with development process (was:Re: pgaccess - the discussion is over) (Myron Scott <mkscott@sacadia.com>) |
Список | pgsql-hackers |
On Tue, 14 May 2002, Myron Scott wrote: > > > Tom Lane wrote: > > > > > > >With a little more intelligence in the manager of this table, this could > >also solve my concern about pointer variables. Perhaps the entries > >could include not just address/size but some type information. If the > >manager knows "this variable is a pointer to a palloc'd string" then it > >could do the Right Thing during fork. Not sure offhand what the > >categories would need to be, but we could derive those if anyone has > >cataloged the variables that get passed down from postmaster to children. > > > >I don't think it needs to be a hashtable --- you wouldn't ever be doing > >lookups in it, would you? Just a simple list of things-to-copy ought to > >do fine. > > > > > I'm thinking in a threaded context where a method may need to lookup a > global that is not passed in. But for copying, I suppose no lookups > would be neccessary. if we can, can we keep the whole 'threaded' concept in mind when developing this ... if going a hashtable would be required for this, let's go the more complete route and eliminate potential issues down the road ...
В списке pgsql-hackers по дате отправления: