Re: lazy detoasting - Mailing list pgsql-hackers

From Chapman Flack
Subject Re: lazy detoasting
Date
Msg-id 6b93e310-0e34-e1fe-3b5e-5887b557de0d@anastigmatix.net
Whole thread Raw
In response to Re: lazy detoasting  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: lazy detoasting
List pgsql-hackers
On 04/11/2018 11:33 AM, Tom Lane wrote:
> Chapman Flack <chap@anastigmatix.net> writes:
>> The mission is to implement java.sql.SQLXML, which has long been
>> missing from PL/Java.
>> This is the class of object your Java code can retrieve from a
>> ResultSet row from a query with an XML column type. (It's also
>> what can be passed to you as a function parameter, if your
>> function's SQL declaration has a parameter type XML.)
> 
> OK, but if this object only lives within a single function call,
> what's the problem?  The underlying row must be visible to the
> calling query, and that condition won't change for the duration
> of the call.

Well, the devilsAdvocate() function would stash the object
in a static, then try to look at it some time in a later call
in the same transaction.

Mind you, I have no use case in mind for a function wanting to do that
(other than as a test case for spec compliance). But the API spec for
the SQLXML class expressly says "object is valid for the duration
of the transaction", and I try not to renege on spec guarantees
if I can find a practical way not to.

> Things could get interesting if you consider a Java *procedure*,

and, yes, that. Though so far, there still are no PL/Java *procedures*.
I haven't even been following that development closely enough yet to
think about what a plan for supporting those would require.

-Chap


pgsql-hackers by date:

Previous
From: "Joshua D. Drake"
Date:
Subject: Re: Creation of wiki page for open items of v11
Next
From: Bruce Momjian
Date:
Subject: Re: 'make check' fails