Re: [HACKERS] RustgreSQL

> It seems someone tried (perhaps ran out of steam, unfortunately): > * Postgres extensions written in Rust * > https://github.com/thehydroimpulse/postgres-extension.rs There is another effort which looks active and promising: (R)ust (P)ost(g)res FFI https://github.com/posix4e/rpgffi This is

Re: [HACKERS] RustgreSQL

On Mon, Jan 09, 2017 at 12:51:43PM -0500, Robert Haas wrote: > On Sun, Jan 8, 2017 at 4:59 AM, Gavin Flower > wrote: > >> Is this completely unrealistic or is it carved in stone PostgreSQL will > >> always be a C project forever and ever? > >> > > From my very

Re: [HACKERS] RustgreSQL

On 2017/01/11 8:02, Josh Berkus wrote: > On 01/09/2017 05:54 PM, Joel Jacobson wrote: >> On Mon, Jan 9, 2017 at 3:22 PM, Jim Nasby 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

Re: [HACKERS] RustgreSQL

On 10 January 2017 at 23:10, otheus uibk wrote: > Craig, isn't it the case that C++ exceptions still cause tremendous > slow-downs of the entire code-base? No, and it hasn't been so for a long time even for gcc. See e.g.

Re: [HACKERS] RustgreSQL

On 01/09/2017 05:54 PM, Joel Jacobson wrote: > On Mon, Jan 9, 2017 at 3:22 PM, Jim Nasby 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

Re: [HACKERS] RustgreSQL

On Tue, Jan 10, 2017 at 12:24 PM, Joshua D. Drake wrote: > In human terms, C is the only one of these that has been around long enough > to realize it isn't a teenager (or child really), and although you may still > be able to do the things you could in your 20s, you are

Re: [HACKERS] RustgreSQL

On 01/10/2017 08:12 AM, Robert Haas wrote: Really? What language would you pick in a vacuum? The Linux kernel is written in C, too, for pretty much the same reasons: it's the canonical language for system software. I don't deny that there may be some newer languages out which could

Re: [HACKERS] RustgreSQL

On Tue, Jan 10, 2017 at 10:55 AM, Tom Lane wrote: > Robert Haas writes: >> I'm not meaning to be funny or sarcastic or disrespectful when I say >> that I think C is the best possible language for PostgreSQL. It works >> great, and we've got a ton of

Re: [HACKERS] RustgreSQL

On Tue, Jan 10, 2017 at 7:48 AM, Robert Haas wrote: > I'm not meaning to be funny or sarcastic or disrespectful when I say > that I think C is the best possible language for PostgreSQL. It works > great, and we've got a ton of investment in making it work. I can't > see

Re: [HACKERS] RustgreSQL

Robert Haas writes: > I'm not meaning to be funny or sarcastic or disrespectful when I say > that I think C is the best possible language for PostgreSQL. It works > great, and we've got a ton of investment in making it work. Yeah. There's certainly a whole lot of path

Re: [HACKERS] RustgreSQL

Joel Jacobson j...@trustly.com wrote: > My motivation is primarily I don't want to learn all the over-complicated details of C, That's rich, mate. C is one of the simplest languages. It's simplicity is its main benefit and its biggest drawback: it shields very little from the actual underlying

Re: [HACKERS] RustgreSQL

On Tue, Jan 10, 2017 at 8:42 AM, Jan de Visser wrote: > Be that as it may, I don't think you have convinced anybody that that is > something worth doing. The fact it *could* be done doesn't mean it *should* be > done. +1. > What you are proposing is not going to happen

Re: [HACKERS] RustgreSQL

On Monday, January 9, 2017 7:39:49 PM EST Joel Jacobson wrote: > On Mon, Jan 9, 2017 at 6:03 PM, Craig Ringer wrote: > > Immutable functions can and do use functionality from all over the > > server. They just don't depend on user-visible mutable _state_ > > elsewhere in

Re: [HACKERS] RustgreSQL

On Mon, Jan 9, 2017 at 6:03 PM, Craig Ringer wrote: > Immutable functions can and do use functionality from all over the > server. They just don't depend on user-visible mutable _state_ > elsewhere in the server. OK, fair point, but at least the functionality *could* be

Re: [HACKERS] RustgreSQL

On 10 January 2017 at 09:54, Joel Jacobson wrote: > 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

Re: [HACKERS] RustgreSQL

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

Re: [HACKERS] RustgreSQL

On 1/9/17 11:51 AM, Robert Haas wrote: Anyway, with regards to either Rust (which I know very little about) or C++ (which I know more about) I think it would be more promising to think about enabling extensions to be written in such languages than to think about converting the entire source

Re: [HACKERS] RustgreSQL

On 1/9/17 3:15 AM, Pavel Stehule wrote: The running unsafe PL in own managed processes is good idea - Years, I have a one diploma theme "better management of unsafe PL in Postgres" - but still without any interest from students :(. I had two possibilities to see catastrophic errors related to

Re: [HACKERS] RustgreSQL

On Sun, Jan 8, 2017 at 4:59 AM, Gavin Flower wrote: >> Is this completely unrealistic or is it carved in stone PostgreSQL will >> always be a C project forever and ever? >> > From my very limited understanding, PostgreSQL is more likely to be > converted to C++!

Re: [HACKERS] RustgreSQL

2017-01-09 1:21 GMT+01:00 Jim Nasby : > On 1/8/17 5:56 PM, Greg Stark wrote: > >> On 8 January 2017 at 21:50, Jim Nasby wrote: >> >>> Somewhat related to that... it would be useful if Postgres had "fenced" >>> functions; functions that ran in a

Re: [HACKERS] RustgreSQL

On 1/8/17 5:56 PM, Greg Stark wrote: On 8 January 2017 at 21:50, Jim Nasby wrote: Somewhat related to that... it would be useful if Postgres had "fenced" functions; functions that ran in a separate process and only talked to a backend via a well defined API (such as

Re: [HACKERS] RustgreSQL

On Monday, January 9, 2017 7:06:21 AM EST Craig Ringer wrote: > On 9 Jan. 2017 05:51, "Jan de Visser" wrote: > > On Sunday, January 8, 2017 6:28:17 AM EST Joel Jacobson wrote: > > I don't want to learn the complicated details of C, that's true. > > And this is where I think

Re: [HACKERS] RustgreSQL

On 8 January 2017 at 21:50, Jim Nasby wrote: > Somewhat related to that... it would be useful if Postgres had "fenced" > functions; functions that ran in a separate process and only talked to a > backend via a well defined API (such as libpq). There's two major

Re: [HACKERS] RustgreSQL

On 01/08/2017 09:19 AM, Craig Ringer wrote: On 8 Jan. 2017 17:10, "Joel Jacobson" > wrote: Is this completely unrealistic or is it carved in stone PostgreSQL will always be a C project forever and ever? Incredibly unrealistic. [lots of

Re: [HACKERS] RustgreSQL

On 1/8/17 5:06 PM, Craig Ringer wrote: It is very hard to write C that is generally portable, robust in the face of various edge-case inputs and environmental conditions, are free from race conditions and memory ordering problems, and rely on no undefined behaviour. BTW, if you s/memory/set/

Re: [HACKERS] RustgreSQL

On 9 Jan. 2017 05:51, "Jan de Visser" wrote: On Sunday, January 8, 2017 6:28:17 AM EST Joel Jacobson wrote: > I don't want to learn the complicated details of C, that's true. And this is where I think you're wrong, and why conversion would be hard. C has very few complicated

Re: [HACKERS] RustgreSQL

On 09/01/17 11:31, Michael Paquier wrote: On Mon, Jan 9, 2017 at 6:51 AM, Jan de Visser wrote: Your fear of C in unfounded. The definitive c89 reference is a little book of about 250 pages, more than half of which is about the standard library of which you'll never use more

Re: [HACKERS] RustgreSQL

On Sun, Jan 8, 2017 at 1:51 PM, Jan de Visser wrote: > And this is where I think you're wrong, and why conversion would be hard. C > has very few complicated details. I don't think it has any, frankly. It > basically says "If you want your datastructure to outlive a function

Re: [HACKERS] RustgreSQL

On Mon, Jan 9, 2017 at 6:51 AM, Jan de Visser wrote: > Your fear of C in unfounded. The definitive c89 reference is a little book of > about 250 pages, more than half of which is about the standard library of > which you'll never use more than half. If you have some notepaper

Re: [HACKERS] RustgreSQL

On Sunday, January 8, 2017 6:28:17 AM EST Joel Jacobson wrote: > I don't want to learn the complicated details of C, that's true. And this is where I think you're wrong, and why conversion would be hard. C has very few complicated details. I don't think it has any, frankly. It basically says

Re: [HACKERS] RustgreSQL

On 1/8/17 10:28 AM, Joel Jacobson wrote: You'd have a lot more chance writing extensions in Rust though. If you can make it play OK with the exception handling in postgres and our memory management, at least. If you really wanted to push this forward... start there. Show how great it is.

Re: [HACKERS] RustgreSQL

Thank you Craig for explaining the current C state of the project, very interesting to learn about. On Sun, Jan 8, 2017 at 4:19 AM, Craig Ringer wrote: > If a low pain seamless conversation/adaptation like that were possible I'd > have to wonder what Rust could

Re: [HACKERS] RustgreSQL

Is this completely unrealistic or is it carved in stone PostgreSQL will always be a C project forever and ever? Another thing to look at if you want to approach this as a serious, practical effort is the atomics, memory barrier, spinlock and lwlock code. I just don't see it happening.

Re: [HACKERS] RustgreSQL

On 8 Jan. 2017 18:14, "Fabien COELHO" wrote: Is this completely unrealistic or is it carved in stone PostgreSQL will >> always be a C project forever and ever? >> > > From my very limited understanding, PostgreSQL is more likely to be > converted to C++! > ISTM that

Re: [HACKERS] RustgreSQL

On 8 Jan. 2017 17:10, "Joel Jacobson" wrote: Is this completely unrealistic or is it carved in stone PostgreSQL will always be a C project forever and ever? Incredibly unrealistic. PostgreSQL makes heavy use of variable length arrays. longjmp() is critical to its error

Re: [HACKERS] RustgreSQL

-BEGIN PGP SIGNED MESSAGE- Hash: RIPEMD160 Joel Jacobson asked: > Is anyone working on porting PostgreSQL to Rust? No; extremely unlikely. > My motivation is primarily I don't want to learn all the > over-complicated details of C Well that's going to be a show-stopper right there.

Re: [HACKERS] RustgreSQL

Is this completely unrealistic or is it carved in stone PostgreSQL will always be a C project forever and ever? From my very limited understanding, PostgreSQL is more likely to be converted to C++! ISTM that currently pg is written C89. Personnaly I think that C99 (standard from 18 years

Re: [HACKERS] RustgreSQL

On 08/01/17 22:09, Joel Jacobson wrote: Hi all, Is anyone working on porting PostgreSQL to Rust? Corrode looks a bit limited for the task, but maybe it can be a start. It doesn't support goto or switch, but maybe the gotos patterns are not too complicated. My motivation is primarily I don't

[HACKERS] RustgreSQL

Hi all, Is anyone working on porting PostgreSQL to Rust? Corrode looks a bit limited for the task, but maybe it can be a start. It doesn't support goto or switch, but maybe the gotos patterns are not too complicated. My motivation is primarily I don't want to learn all the over-complicated