Re: implement prepared queries in plperl
От | Dmitry Karasik |
---|---|
Тема | Re: implement prepared queries in plperl |
Дата | |
Msg-id | 20060306091227.GA16736@tetsuo.karasik.eu.org обсуждение исходный текст |
Ответ на | Re: implement prepared queries in plperl (Andrew Dunstan <andrew@dunslane.net>) |
Список | pgsql-patches |
> >OK, I'll take another look. I'm still curious to know why pltcl > >doesn't need to call spi_free_plan. Maybe it does need to ... > I have committed the patch and docs for this - it's an important feature > and I would like people banging on it. > I'd like to review the API we provide to plperl, though - I don't like > it much. I think that should be an 8.2 TODO. Thanks! If you'd be interested in my opinion, I thought that probably it would be beneficial to have two layers of access to SPI, first, the existing spi_xxx() set, and second, fully object oriented, with 'SPI->new' or 'SPI->query->rows->data' or whatever else imagined. That would've been a good design for an average Perl XS module, because XS layer would only introduced direct mappings to C functions, and the accompanied perl code in .pm file would implement object bells and whistles based on C API as seen from perl. That's a bit bloatish, so I'd understand if you would want to completely rewrite the Perl API, however, I'd propose to do that in two phases: first, introduce object API that is implemented on well-known spi_xxx(), and then, if necessary, get rid of the latter. btw, would be me appropriate to move the discussion into hackers@? -- Sincerely, Dmitry Karasik
В списке pgsql-patches по дате отправления: