Thread: Re: [GENERAL] [HACKERS] SSL and Encryption
On 11/2/2017 9:39 PM, Michael Paquier wrote:
The SCRAM discussion is spread across two threads mainly with hundreds of emails, which may discourage even the bravest. Here are links to the important documentation: https://www.postgresql.org/docs/current/static/auth-methods.html#auth-password
so that says... ... [scram-sha-256] is the most secure of the currently provided methods, but it is not supported by older client libraries....
whats the state of the more popular bindings now? jdbc, python native, etc ?
-- john r pierce, recycling bits in santa cruz
On Thu, Nov 2, 2017 at 9:58 PM, John R Pierce <pierce@hogranch.com> wrote:
On 11/2/2017 9:39 PM, Michael Paquier wrote:The SCRAM discussion is spread across two threads mainly with hundreds of emails, which may discourage even the bravest. Here are links to the important documentation: https://www.postgresql.org/docs/current/static/auth- methods.html#auth-password so that says... ... [scram-sha-256] is the most secure of the currently provided methods, but it is not supported by older client libraries....
whats the state of the more popular bindings now? jdbc, python native, etc ?
What is 'python native'? psycopg works as long you update your libpq.
Cheers,
Jeff
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 ? -- john r pierce, recycling bits in santa cruz -- Sent via pgsql-general mailing list (pgsql-general@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-general
On Fri, Nov 3, 2017 at 5:22 AM, John R Pierce <pierce@hogranch.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 I'm pretty sure they don't. The industry standard uses libpq. -- Daniele -- Sent via pgsql-general mailing list (pgsql-general@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-general
On Thu, Nov 2, 2017 at 10:22 PM, John R Pierce <pierce@hogranch.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 ?
I'm not a pythonista more of a python-when-I-must, but psycopg is the dominant driver I've seen used and discussed. I had to use a different driver (zxJDBC, for jython) and basically all advice I found was for psycopg and not applicable to zxJDBC, which most people apparently had never even heard of.
Anyway, I would think psycopg would be classed as a native binding, as it uses libpq which is 'native' to PostgreSQL.
If someone has greater knowledge here, it would be nice to update the wiki pages with new info.
Talk of what is native or not in pythons now has me thinking of the Everglades.
Cheers,
Jeff
On Fri, Nov 3, 2017 at 4:12 PM, Jeff Janes <jeff.janes@gmail.com> wrote: > On Thu, Nov 2, 2017 at 10:22 PM, John R Pierce <pierce@hogranch.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 -- Sent via pgsql-general mailing list (pgsql-general@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-general