Re: Pass-by-reference UDTs and volatility

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(at)sss(dot)pgh(dot)pa(dot)us> wrote:

> Stephen Scheck <singularsyntax(at)gmail(dot)com> writes:
> > "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?
>
> No.
>
> > 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?
>
> It might well do that; you really do not have the option to create Datum
> 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
>