Hmm, that might work - so allocate the values in a transaction-scoped memory context?
But how would the hash table keys themselves be deleted? Is there some callback API to
hook transaction completion?
On Wed, Jun 12, 2013 at 1:07 PM, Tom Lane <tgl@xxxxxxxxxxxxx> wrote:
Stephen Scheck <singularsyntax@xxxxxxxxx> writes:No.
> "Never modify the contents of a pass-by-reference input value. If you do so
> you are likely to corrupt on-disk data, since the pointer you are given
> might point directly into a disk buffer. The sole exception to this rule is
> explained in Section 35.10."
> If the UDTs the extension defines are the sole producer/consumer of the
> data type and are consistent in the way they manipulate the in-memory data
> structure for the type, can the above rule be safely ignored?
It might well do that; you really do not have the option to create Datum
> Or could the
> backend do something like try to persist intermediate return values from
> functions to temporary hard storage as it proceeds with execution of a
> query plan?
values that can't be copied by datumCopy(). Even more directly, if you
do something like
select foo('...'::pass_by_ref_type)
and foo elects to scribble on its input, it will be corrupting a Const
node in the query plan. You'd probably not notice any bad effects from
that in the case of a one-shot plan, but it would definitely break
cached plans.
Just brainstorming here, but: you might consider keeping the actual
value(s) in private storage, perhaps a hashtable, and making the Datums
that Postgres passes around be just tokens referencing hashtable
entries. This would for one thing give you greatly more security
against user query-structure errors than what you're sketching.
The main thing that might be hard to deal with is figuring out when it's
safe to reclaim a no-longer-referenced value. You could certainly do so
at top-level transaction end, but depending on what your app is doing,
that might not be enough.
regards, tom lane
