Re: [HACKERS] RustgreSQL - Mailing list pgsql-hackers

From Joel Jacobson
Subject Re: [HACKERS] RustgreSQL
Date
Msg-id CAASwCXe8VXhK_28rqH5ugtL4oic+Ybfsmy1aYFb5RfeM30F2WQ@mail.gmail.com
Whole thread Raw
In response to Re: [HACKERS] RustgreSQL  (Jim Nasby <Jim.Nasby@BlueTreble.com>)
Responses Re: [HACKERS] RustgreSQL  (Craig Ringer <craig@2ndquadrant.com>)
List pgsql-hackers
On Mon, Jan 9, 2017 at 3:22 PM, Jim Nasby <Jim.Nasby@bluetreble.com> wrote:
> I do wonder if there are parts of the codebase that would be much better
> suited to a language other than C, and could reasonably be ported.
> Especially if that could be done in such a way that the net result is still
> C code so we're not adding dependencies to non developers (similar to
> bison).
>
> Extensions are a step in that direction, but they're ultimately not core
> Postgres (which is a different issue).

I think this is a great idea!

That way the amount of C code could be reduced over time,
while safely extending the official version with new functionality on
the surface,
without increasing the amount of C code.

One idea of an area that would be most useful from a user-perspective
is probably all pg_catalog functions that are immutable.
They should be able to be written without expertise of the PostgreSQL internals,
since they only depend on the input parameters to produce the output.

And that also means is should be easier to write them in a different
language than C,
because they don't need access to any PostgreSQL internal data structures,
or make use of existing C functions.



pgsql-hackers by date:

Previous
From: Jim Nasby
Date:
Subject: Re: [HACKERS] pg_background contrib module proposal
Next
From: Michael Paquier
Date:
Subject: Re: [HACKERS] Support for pg_receivexlog --format=plain|tar