On Wed, Aug 22, 2001 at 10:38:44PM -0700, Brian Pane wrote: > Greg Stein wrote: >... > >Yes there is. apr_pool_userdata_set(..., r->pool) >... > Using the "userdata" functions on r->pool as a replacement for a > hash-based r->notes would be a mistake. The interface to the userdata > in a pool is limited to "get" and "set" methods. The API is missing > essential operations like "iterate over the set of elements in the userdata" > and "merge the userdata for a subrequest pool into the parent's r->pool." I would posit those operations are not needed. The notes or userdata are for specific bits of information. It is not a simple collection that you can iterate over. In fact, since you can't know the values of each key, you cannot perform a useful iteration nor do a useful merge. Cheers, -g -- Greg Stein, http://www.lyra.org/
- Letting Table store non-char data Ian Holsman
- Re: Letting Table store non-char data Ryan Bloom
- Re: Letting Table store non-char data Ian Holsman
- Re: Letting Table store non-char data Brian Pane
- Re: Letting Table store non-char data Ian Holsman
- Re: Letting Table store non-char data Greg Stein
- Re: Letting Table store non-char data Ryan Bloom
- Re: Letting Table store non-char data Ian Holsman
- Re: Letting Table store non-char data Brian Pane
- Re: Letting Table store non-char data Greg Stein
- Re: Letting Table store non-char data Brian Pane
- Re: Letting Table store non-char data Greg Stein
- Re: Letting Table store non-char data William A. Rowe, Jr.
- Re: Letting Table store non-char data Eric Prud'hommeaux
- Re: Letting Table store non-char data Ryan Bloom
- Re: Letting Table store non-char data Greg Stein
- Re: Letting Table store non-char data William A. Rowe, Jr.