
Show HN: Pg-extend-rs – Easy Postgres extensions in Rust - bluejekyll
https://bluejekyll.github.io/blog/rust/2018/12/27/announcing-pg-extend.html
======
rtpg
Ohhh this is great! I have had a query planner extension idea for a while but
dealing with C bugged me a lot. I think that this might help me try some Rust
ans some Postgres

~~~
bluejekyll
As warning, there’s still a bunch of work to translate various types from Rust
to Postgres Datums.

I’m interested in feedback on the library, so if you use it and experience any
issues, please let me know.

------
sjroot
This made me curious - are there any SQL databases being actively developed in
Rust? I found one on GitHub (LlamaDB) that does not appear to be maintained.

~~~
FBISurveillance
TiKV ([https://github.com/tikv/tikv](https://github.com/tikv/tikv)) is a
database (KV-store to be precise) written in Rust and speaks MySQL protocol.

Toshi ([https://github.com/toshi-search/Toshi](https://github.com/toshi-
search/Toshi)) is Elasticsearch-like engine that uses tantivy (Lucene-like),
both also written in Rust.

~~~
ddorian43
Tikv is key-value. Mysql layer, tidb, is in golang.

~~~
staticassertion
Tidb is built on top of tikv though.

------
MuffinFlavored
What's the purpose of this? Why this over a function in PL/pgSQL?

~~~
derefr
That's a funny comparison. The much more obvious contrast would be to writing
a Postgres extension in C.

Or are you asking, "why have native DBMS extensions at all?" Looking at the
set of native Postgres extensions that currently exist would probably be
enlightening:

• PostGIS, for one. You can't really define those types—and especially, the
algorithms that operate on them—efficiently in PL/pgSQL. In this case, the
extension is native for _low overhead operation_.

• uuid-ossp, for another. To generate the data it does, this extension needs
access to several pieces of data from the OS (e.g. the MAC address of an
Ethernet interface) that you can't access from PL/pgSQL. In this case, the
extension is native _to query native OS data APIs_.

• Citus, for a third. Citus basically changes Postgres's runtime "operational
architecture" in several fundamental ways. It augments the Postgres
Postmaster, changes how replication works, etc. None of this is possible from
PL/pgSQL. In this case, the extension is native _to use native OS threading
and IPC APIs to override how Postgres works_.

(And that's ignoring the fact that having native extension support usually
gets you ABI compatibility with the embeddable runtimes of most other
languages, allowing you to then support things like Python or Java—and thus
get access to low-overhead shared-memory+FFI-based "IPC" with existing
libraries in those languages, rather than needing to have them run as co-
servers and communicate over sockets. Which, in turn, gets you the ability to
cheaply and easily use _client libraries_ written in those languages to create
Postgres Foreign Data Wrapper libraries for Datomic, or Elastic, or the AWS
Public Dataset API, or whatever other weird-API-with-relatively-few-library-
impls you like.)

~~~
joevandyk
I thought uuid-ossp was just a bunch of utilities around uuid parsing and
generation. It shouldn’t need anything special from the OS.

[https://www.postgresql.org/docs/9.4/uuid-
ossp.html](https://www.postgresql.org/docs/9.4/uuid-ossp.html)

~~~
derefr
A UUIDv1 contains the host's MAC address as a component. And the uuid-ossp
extension (or rather, the OSSP's libuuid, which it uses) does indeed read said
MAC address when building UUIDv1s: [https://github.com/sean-/ossp-
uuid/blob/master/uuid_mac.c](https://github.com/sean-/ossp-
uuid/blob/master/uuid_mac.c)

Keep in mind, if you're using uuid-ossp rather than just relying on Postgres's
built-in gen_random_uuid() function, it's _very likely_ because you want to
generate UUIDv1s instead of UUIDv4s (as they're the only two types of UUIDs
that see much use.) So this functionality is pretty essential to the
extension—a version of the extension without it wouldn't be worth much.

------
InGodsName
Does it have additional overheard compared to rolling in C/c++?

~~~
bluejekyll
Right now, the only additional overhead I can think of would be on transforms
from Rust style Strings and &str's to C style CString and CStr's.

Beyond that, I think it should be nearly identical with C/C++.

