Re: [HACKERS] RustgreSQL

Поиск
Список
Период
Сортировка
От Joel Jacobson
Тема Re: [HACKERS] RustgreSQL
Дата
Msg-id CAASwCXe8VXhK_28rqH5ugtL4oic+Ybfsmy1aYFb5RfeM30F2WQ@mail.gmail.com
обсуждение исходный текст
Ответ на Re: [HACKERS] RustgreSQL  (Jim Nasby <Jim.Nasby@BlueTreble.com>)
Ответы Re: [HACKERS] RustgreSQL  (Craig Ringer <craig@2ndquadrant.com>)
Список 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 по дате отправления:

Предыдущее
От: Jim Nasby
Дата:
Сообщение: Re: [HACKERS] pg_background contrib module proposal
Следующее
От: Michael Paquier
Дата:
Сообщение: Re: [HACKERS] Support for pg_receivexlog --format=plain|tar