This is certainly possible. If you know the binary structure of the data that libpq sends and recieves from PostgreSQL, then you can mimic libpq.
I sincerely doubt anyone has ever tried this due to it being insane.
What is wrong with using libpq?
Thanks John... 1) For me its insane to have to compile the libpq, ssh libraries, etc (or use other libraries with extra functionality I do not need) to be able to access to a postgresql database 2) the functionality included in libpq is duplicated partially in grand_dispatch and foundation (for example async, processeses)... As you said, only the binary structure needs to be known. I am not saying it is easy. With libpq we are using an extra layer (c language) which is not needed if we communicate directly with the server.
Given that it's almost always a bad idea to use the direct connection API on an SQL database server (in every practical situation, you're better off writing your own front end for security and access control, among other reasons), it shouldn't really be surprising how much work that is. There's basically no reason for anyone to sit down and port the C-based library to Swift.
Check out ths GitHub project - it sounds exactly like what you need: github.com/spacialdb/libpq.framework
libpq only needs crypto and ssl. It is unusual for an open-source package to have so few dependencies. There is a version of libpq installed with Xcode, but it is only for Apple's internal use. You won't be able to link against it.
There is no duplicate functionality. There may be different APIs that perform the same general tasks, but that is not the same thing. Since libpq only depends on crypto and ssl, those other APIs must already exist in the system. Apple provides a number a different threading and IPC APIs. You can pick the ones you want. Apple typically recommends using the highest level API available. Those are unlikely to be GCD and foundation. I prefer to use cross-platform POSIX APIs whenever possible. They are well-documented, stable, and easier to use than anything Apple provides. I have tried to use the GCD IO API multiple times but finally gave up. It is very complex and poorly documented. The exact semantics for use are unknown outside of Apple, and possible inside too. If Apple breaks one of these POSIX APIs, they break lots of code, including their own. I can complain about that and get attention. But if my GCD code doesn't work, I'm on my own.
The C language is not an extra layer. The entire OS, including Swift itself, it written in C. (Actually it looks like Swift is written in C++, yet another layer.) Those other libraries like lib_dispatch and foundation are written in C and/or Objective-C.
If you just wanted to write some extra code that you didn't need, you could try porting libpq to use Apple's Security framework. That would be far easier and more straightforward. Or how about an OpenSSL compatibility layer that uses the Security framework underneath? That would be appreciated by many people outside of the relatively small libpq community.
Late to the party, but in case it helps anyone...
I recently wanted the same thing: a Postgres driver for Swift that didn't require libpq. I found a few projects in GitHub, but they were either abandoned or missing features I wanted (e.g. SSL/TLS, type coercion). So I ended up building my own framework, which is available on GitHub.
The Postgres wire protocol is straightforward and well documented. So this was a fairly painless exercise.