Pass-by-reference UDTs and volatility - Mailing list pgsql-general

From Stephen Scheck
Subject Pass-by-reference UDTs and volatility
Date
Msg-id CAKjnHz0UjSG9AYfhF2nKbysbanxWWRWdzGS+JHmLN_w6pmvBAA@mail.gmail.com
Whole thread Raw
Responses Re: Pass-by-reference UDTs and volatility  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-general
Hello,

I am working on an extension which defines a number of user-defined functions which will operate on a common, custom data type to perform a pipeline of transformations (the data type is the IN/OUT parameter for all of the functions), eventually being supplied to a sink function which takes the data type as input and produces tuple(s) as output. A source function will produce the initial instance of the data type and feed it to the head of the pipeline. As such, the data type only ever exists in memory and is never intended to be used as a column of a table or persisted to disk.

What I would really like is something like the "internal" pseudo-type that can be used to define the functions, but is not allowed to be used as a column type in a table. However, since these functions must be callable from a user context, "internal" will not work. I'm not that concerned with users trying to use the data type in table DDL as they can simply be instructed not to in documentation (and suffer the consequences of their actions if they don't read the fine manual). However, in chapter 35.9 of the Postgres docs, there is this warning:

"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? 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?

Thanks.

pgsql-general by date:

Previous
From: Stephen Scheck
Date:
Subject: Explicit LOAD and dynamic library loading
Next
From: Alvaro Herrera
Date:
Subject: Re: Get data type aliases