Bruce Momjian <pgman@candle.pha.pa.us> writes:
>> If we are going to do this, we ought also think about solving the
>> generic memory-leakage problem at the same time. No point in having
>> to revisit all the same code later to deal with that issue.
> I have a good fix for this. My patch suggested the varlena routine
> pfree the pointer returned from expand_long(). No need for that. With
> an LRU cache, we can have the cache itself free the old values.
Oooh, that's a thought. Sort of like applying TupleTableSlot to
individual datum values.
> There aren't any cases where the varlena access routines access more
> than two varlena values at the same time.
Huh? The standard operators on varlena types access at least three (two
inputs and a result), and multi-argument functions could access more.
Also think about functions written in PLs: they could invoke a large
amount of computation, and would still expect to be able to access their
original input arguments.
I'd feel more comfortable with explicit reference counting. Perhaps
we could make an exception for function return values: the cache
guarantees to hold onto a function return value for a little while
even though no one is holding a refcount on it at the instant it's
returned. Functions (including PL functions) that want to access
varlena values across any significant amount of computation would
have to bump the refcount on those values somehow.
> I am excited about the long data type. This is _the_ way to do long
> data types. Have any of the commercial databases figured out this way
> to do it. I can't imagine a better system.
I think we are working on some really cool ideas here. But I *don't*
think we have a solid enough hold on all the details that we can expect
to implement it and ship it out one-two-three. Thus my feeling that
this is for 7.1 not 7.0...
regards, tom lane
