Re: Rewriting pg_upgrade (was Re: State of Beta 2)

From: Greg Stark <gsstark(at)mit(dot)edu>
To: pgsql-general(at)postgresql(dot)org
Subject: Re: Rewriting pg_upgrade (was Re: State of Beta 2)
Date: 2003-09-28 05:45:49
Message-ID: 87eky1fotu.fsf@stark.dyndns.tv
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-general


Ron Johnson <ron(dot)l(dot)johnson(at)cox(dot)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

In response to

Browse pgsql-general by date

  From Date Subject
Next Message Shridhar Daithankar 2003-09-28 10:08:36 C/C++/Java [was Re: State of Beta 2]
Previous Message Ron Johnson 2003-09-28 04:06:50 Re: State of Beta 2