Re: implement prepared queries in plperl
От | Dmitry Karasik |
---|---|
Тема | Re: implement prepared queries in plperl |
Дата | |
Msg-id | 20060302070839.GB58286@tetsuo.karasik.eu.org обсуждение исходный текст |
Ответ на | Re: implement prepared queries in plperl (Andrew Dunstan <andrew@dunslane.net>) |
Ответы |
Re: implement prepared queries in plperl
|
Список | pgsql-patches |
> Bruce Momjian wrote: > >Is this patch going to be applied? > I am waiting for an update from Dmitry. > cheers > andrew I believe this is some kind of misunderstanding, sorry if from my part, but I don't think any further updates are necessary. > >>But why do we have to call spi_freeplan? pltcl, which has prepared > >>queries, doesn't require this AFAICS. If memory leaks are an issue, > >>maybe we should bless the object into a class with a DESTROY method that > >>calls spi_freeplan automatically (not sure to do that in XS but I assume > >>it's possible). I remember though that my answer to this question didn't hit the list so it's here again, in case that was meant by 'the update': I thought of that, indeed the automatic cleanup would be better from one point of view, but I thought also about that the existing SPI interface is not object-oriented, so I've extended it in functional style, and that the mirroring of C SPI functions into Perl would be less encumbered by glue layers, and again, implementing such a glue layer on top of new spi_ functions would be trivial. I also remember I heard about plans about writing a DBI-style API over SPI, and thought that such (future/imaginary) layer would be ideal for implementing queries as objects ( including DESTROY ). Another thing, automatic destruction of a query would prohibit passing the query handle outside a perl function where the handle has the scope. True, it is possible to keep the reference count and the handle from destruction in $_SHARED{}, if necessary, but when finally the handle has to be released, a wrapper for spi_freeplan() has to be called anyway. -- Sincerely, Dmitry Karasik
В списке pgsql-patches по дате отправления: