On 4/8/19 4:20 PM, Alvaro Herrera wrote:
> On 2019-Apr-08, Jonathan S. Katz wrote:
>
>> On 4/8/19 4:10 PM, Alvaro Herrera wrote:
>
>>> I wonder why we have two pages
>>> https://wiki.postgresql.org/wiki/Client_Libraries
>>> https://wiki.postgresql.org/wiki/List_of_drivers
>>
>> No clue, but it appears that first one is the newer of the two[1][2]
>>
>> I'd be happy to consolidate them and provide a forwarding reference from
>> Client Libraries to List of Drivers, given I think we reference "List of
>> Drivers" in other places.
>
> There are two links to List of drivers, and one of them is in Client
> Libraries :-)
> https://wiki.postgresql.org/wiki/Special:WhatLinksHere/Client_Libraries
>
> +1 for consolidation and setting up a redirect.
OK, so trying to not be too off topic, I did update the original page as so:
https://wiki.postgresql.org/wiki/List_of_drivers
When determining what to add, I tried to keep it one-abstraction level
deep, i.e., a driver is implemented on top of libpq, implemented the PG
protocol on its own, or did some driver-like extensions on top of the
base language driver. I steered clear of ORMs or other abstraction
layers unless they met the above criteria.
(There are a lot of handy ORM-ish abstraction layers as well, but I
don't want to go down that path on that page, at least not today).
I also added a deprecation warning on top of the "Client Libraries"
page. If we're feeling satisfied with the consolidation, I'll wipe the
content and indicate where the maintained content is and end the
split-brain situation.
(One thing that I will say is this is one of those sections that may be
worth moving to pgweb, to give it some semi-permanence. Separate
discussion.)
The good news: while going through the added drivers, most of the
non-libpq ones I've added do support SCRAM :)
That said, I am still in favor of the PG13 plan, and without objection I
would like to reach out to the driver authors in the "no" category,
reference this thread, and that this is at least discussed, if not
decided upon, and they should considering adding support for SCRAM to
allow adequate testing time as well as time for their drivers to make it
into appropriate packaging systems.
Jonathan
