PL/Java has gone through a series of stability improvements over the
last couple of weeks. Now it's time to perhaps improve things even more
but that requires a little help from PostgreSQL itself (nothing related
to threads though ;-) )
PL/Java has various "wrapper" objects for PostgreSQL structures. In
essence, such a wrapper holds on to a pointer to some structure and
dispatch calls to backend functions. The challenge is to make sure that
the wrapped pointer is valid at all times. PL/Java uses three distinct
approaches to accomplish this:
1. The structure is copied into a special MemoryContext that PL/Java
manages and is thus valid throughout the life cycle of the wrapper.
2. The structure is considered "call local", i.e. the wrapper is
invalidated when the current call-handler call returns.
3. The structure has an associated callback that can be used in order to
invalidate the wrapper when the structure is freed up.
At present, the only wrapper that uses category #3 is the Portal wrapper
and that solution is a bit ugly. I currently replace the portal->cleanup
function pointer with a function that invalidates the wrapper and then
calls the original cleanup. This solution will break as soon as someone
decides that different portals can have different cleanup functions (and
I guess that's the reason for having the function pointer in the first
place).
I need some advice on how to improve this. The issues that I see are:
- the portal callback problem. Would it be feasible to install a proper
callback registration on portals?
- unnecessary copying. Since several structures doesn't have callbacks
but can be copied, I'm always copying them.
- I'd like to know when the return value of a function goes out of
scope. "call-local" is often premature since the structure might survive
and be used in the calling function (which may be Java also).
Ideally, I'd like callback functionality on a number of structures,
Portal, HeapTuple, TupleDesc, Relation, LargeObjectDesc, and
ExecutionPlan in particular.
Hmm, and the HeapTupleHeader that is passed to RECORD functions, is
there an easy way to transform that into a HeapTuple?
Kind regards,
Thomas Hallgren
---------------------------(end of broadcast)---------------------------
TIP 9: In versions below 8.0, the planner will ignore your desire to
choose an index scan if your joining column's datatypes do not
match
