Re: RustgreSQL

From: Joel Jacobson <joel(at)trustly(dot)com>
To: Jim Nasby <Jim(dot)Nasby(at)bluetreble(dot)com>
Cc: Robert Haas <robertmhaas(at)gmail(dot)com>, Gavin Flower <GavinFlower(at)archidevsys(dot)co(dot)nz>, Pg Hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: RustgreSQL
Date: 2017-01-10 01:54:40
Message-ID: CAASwCXe8VXhK_28rqH5ugtL4oic+Ybfsmy1aYFb5RfeM30F2WQ@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Mon, Jan 9, 2017 at 3:22 PM, Jim Nasby <Jim(dot)Nasby(at)bluetreble(dot)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.

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Michael Paquier 2017-01-10 02:01:00 Re: Support for pg_receivexlog --format=plain|tar
Previous Message Jim Nasby 2017-01-10 01:39:53 Re: pg_background contrib module proposal