Re: [HACKERS] SSL and Encryption

On Fri, Nov 3, 2017 at 4:12 PM, Jeff Janes <jeff(dot)janes(at)gmail(dot)com> wrote:
> On Thu, Nov 2, 2017 at 10:22 PM, John R Pierce <pierce(at)hogranch(dot)com> wrote:
>>
>> On 11/2/2017 10:12 PM, Jeff Janes wrote:
>>>
>>> https://wiki.postgresql.org/wiki/List_of_drivers
>>>
>>> What is 'python native'? psycopg works as long you update your libpq.
>>
>> I thought pythonistas preferred using a native driver that didn't use
>> libpq ?
>
> Anyway, I would think psycopg would be classed as a native binding, as it
> uses libpq which is 'native' to PostgreSQL.

"Native" in the context of a Python library refers to a library
written in pure Python, which can run with any implementation of the
Python language: in C (CPython, the canonical implementation), in Java
(JPython), in .NET (IronPython), in Python (PyPy)... As such psycopg2
is not a native library because it's written in C and designed only
for CPython.

Notice that "native" and "using the libpq" are not mutually exclusive:
using FFI it is possible to load dynamically the libpq and have pure
Python code calling into the libpq, without the need to build a Python
C extension. This is the case of psycopg2-ctypes and psycopg2cffi,
which are drop-in replacements for psycopg2 (I contributed to the
-ctypes variant at the time and made sure of its interface by dropping
in the entire psycopg2 test suite and hammering it until all tests
passed; -cffi forked from it). Both projects feature-wise seem stuck
to psycopg 2.5 era (circa 2012); psycopg2-ctypes seems unmaintained,
psycopg2cffi seems still maintained instead, with a release a few
months ago (unfortunately with a confusing version number). These
projects are inherently slower than the C psycopg2, which performs
more operations in C, but because PyPy has a JIT is roughly makes up
for the speed lost implementing certain inner loops in Python.

Another way to be Python-native is to do without libpq and to parse
the client-server protocol in python. Of course this misses new
features, encryption schemas, and requires the reimplementation in
python of a lot of subtleties (env vars, service files...) that a
libpq-binding solution has for free. The most known example of such
driver is pg8000, which is barely used and barely maintained (had a
release in recent times after a long lull).

In terms of what the industry uses, ISTM almost everyone uses the
psycopg2 with CPython, with psycopg2cffi used by PyPy users, which
apparently do ok without the new features introduced in following
psycopg versions (replication, SQL composition...). Apart from
CPython, targeting PyPy is the only meaningful goal as JPython and
IronPython are not so used anymore. pg8000 and other drivers are just
not very used.

> If someone has greater knowledge here, it would be nice to update the wiki
> pages with new info.

I've added a link to psycopg2cffi. I don't think mentioning other
drivers is really useful for concrete and current use cases.

-- Daniele