Ron Johnson <ron.l.johnson@cox.net> writes:
> > > Tom Lane wrote:
> > > > The reason that it needs to be rewritten in C is that it needs access to
> > > > internal stuff that the backend doesn't expose. (For example, the
> > > > transaction counter, end-of-WAL pointer, etc.) I don't think Perl would
> > > > offer anything except creating an entirely new dependency for Postgres.
> > > > Also, C code would be easier to keep in sync with the backend code that
> > > > accesses the same stuff.
> What about Perl w/ C modules? Of course, there's my favorite: Python.
Fwiw, it's pretty easy to call out to C functions from perl code these days.
bash-2.05b$ perl -e 'use Inline C => "int a(int i,int j) { return i+j;}"; print(a(1,2),"\n")'
3
That said I don't know if this is really such a good approach. I don't see why
you would need much string manipulation at all. The C code can just construct
directly whatever data structures it needs and call directly whatever
functions it needs. Doing string manipulation to construct dynamic sql code
and then hope it gets interpreted and executed the way it's expecting seems a
roundabout way to go about getting things done.
--
greg
