Re: implement prepared queries in plperl - Mailing list pgsql-patches

From Dmitry Karasik
Subject Re: implement prepared queries in plperl
Date
Msg-id 20060306091227.GA16736@tetsuo.karasik.eu.org
Whole thread Raw
In response to Re: implement prepared queries in plperl  (Andrew Dunstan <andrew@dunslane.net>)
List 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 by date:

Previous
From: "Magnus Hagander"
Date:
Subject: Re: LDAP auth
Next
From: Bruce Momjian
Date:
Subject: Re: LDAP auth