Re: lazy detoasting
От | Chapman Flack |
---|---|
Тема | Re: lazy detoasting |
Дата | |
Msg-id | 6b93e310-0e34-e1fe-3b5e-5887b557de0d@anastigmatix.net обсуждение исходный текст |
Ответ на | Re: lazy detoasting (Tom Lane <tgl@sss.pgh.pa.us>) |
Ответы |
Re: lazy detoasting
|
Список | 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 по дате отправления: