Re: Postgres.js driver - for Node.js

--qjaKDroskCt6Kqqv
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

Greetings,

* Jonathan S. Katz ([email protected]) wrote:
> On 1/8/20 7:59 PM, Tom Lane wrote:
> > "Jonathan S. Katz" <[email protected]> writes:
> >> On 1/8/20 7:00 PM, Jonathan Buhacoff wrote:
> >>> I'm wondering if the short list in the documentation [2] could be
> >>> replaced with a link to the corresponding wiki page [1] ?
> >=20
> >> ...
> >> Also, while scanning the list, I also saw that someone recently added
> >> several drivers that appear to be non-OSS.
> >=20
> > Yeah, the lack of curation there is exactly why we generally *don't* li=
nk
> > to the wiki from the formal docs.  We should make more of an effort to
> > transpose vetted info about this topic into the docs, though.
>=20
> I'd be fine with taking a crack at this. I had some notes (I think I put
> it on -hackers during the SCRAM discussion) on how I reorganized the
> list, with what determined what was on the list, and what was an
> unsupported driver.

I agree with putting useful and vetted info into the docs, in general.

> >> ... I will wait until there is some
> >> consensus before removing the other closed-source ones.
> >=20
> > Hm.  I'd vote against including those in the docs' list, because we can=
't
> > as-a-community review their quality and suitability.=20
>=20
> 100% agree there.

I agree that we can't- but I'm also of the opinion that if we're going
to care about things the we "as-a-community" have reviewed, then we need
to actually *do* such a review, at some level, and not just list
everything there that is OSS.

There's a couple of levels of review here, at least imv-

a) It's a driver maintained by someone in the community who is active
   and takes responsibility for it (and therefore presumably either
   wrote the code or has done some amount of code-level review)

b) It's a driver that's been packaged by the community and is
   distributed through community resources

The items in 'a' are also, again in my personal view, eligible for
hosting on pginfra- things like the ODBC driver and the JDBC driver.
The items in 'b' probably also make sense to list and we expect the
packager to at least take some responsibility for dealing with issues,
even if they haven't done a code-level review.  It'd be nice if we
distinguished between those two somehow, but I'm not sure it's really
required.

I'm pretty skeptical about listing drivers beyond those categories in
our official documentation as it lends our credibility to them while
being completely outside of our control.

> > However, I'm not
> > sure that there's anything wrong with having them in the wiki's list
> > as long as they're appropriately marked as not-OSS.
>=20
> I had an offline suggestion about including a "License" column, which
> seems like a good idea in general as we also have in the docs. And if we
> are going to include more drivers in the docs, we'd (read "I'd" for this
> first pass) have to pull those together anyway.

I agree with having a license column (*cough* I might have also been the
one to make the offline suggestion, so don't consider this an
independent advocating of that ;).

> My personal preference would be to at least separate the open source
> from the closed source, but certain things we include in the column
> (e.g. supports SCRAM) we would not be able to validate on a closed
> source driver. But perhaps if we include said drivers on that page, we'd
> not include that info.

I don't think I agree with this- we don't validate anything for a closed
source driver, or an open source driver, to have it be listed on the
wiki- we don't really even control the wiki and we shouldn't be acting
like we do.  We can include if the driver supports SCRAM or not and
people can add that info in about whatever driver they're adding to the
list- or leave it blank if they don't know, and then someone else with
that info can choose to fill it in if they want.

> (Also my preference with the closed source drivers would be to keep them
> listed here:
> https://www.postgresql.org/download/products/2-drivers-and-interfaces/
> ...which I realized adds yet another twist to this discussion because
> one could then say "Why not list them all here?" And then it is a
> curated listed as it goes through the pgweb team...and then we could
> potentially link it from the docs...)

Linking it from the docs has the same issues as noted before though..
Maybe you could generate the docs by pulling from that list but I'm not
really a fan of that either..

Another option though would be to have the list of things from category
'a' and 'b' above be in our docs and then a link to the
drivers-and-interfaces page from the docs, and let people do what they
want with the wiki (maybe put a link at the top of such a page to the
official documentation page though, which makes it clearer that the wiki
isn't the official project position or curated list).

Thanks,

Stephen

--qjaKDroskCt6Kqqv
Content-Type: application/pgp-signature; name="signature.asc"

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1

iQIcBAEBCgAGBQJeF1wmAAoJEO1sijiDR2RV0xAQALQzzONVZKTB3N52EZmXEO0b
SW3f4o8CdRlclBqfjEsAoohwcAYATsAJFM1l4bT8/cBVbWcDmxWUgyV4vz/b1mmZ
RQL2iDLqQzmyLboonBU8EOkP496PaSWo4f6pFghYZs7jBMlj82LfXpmEJqb9c97e
qpUr29DVy7YGm23jIxGx0Cwi4KFXzi0shBa2Ki7WwmT4BqGrxBSdR5uJSkcagPAR
BBqKrn70oTsdolvzc7z7T1MxMRht6S9Lb/COJf5hnF8jYguW2a4iQ2g7zteQA9JL
BwHWmooG9WZlBmKNCE/JsKJCIdkf0rPyYHRWu7N8fI6Q2mcZTfUHRN7sy0nsMWWQ
QGZYP75kbSosv27qj9qid9EK4EwTZ6tuheFvuXvKuocyy2MHHYmwpiw9eVXSuHBy
t4fg2OqVZ+kI9nwkVjTF1M7l0aOkYzTBXzuvltvLlkKhHyl9llBcpU+vpEh7Xn5q
Zk1S3dpkRA2gzfkfSzXMupAPF2P7tK0BM6+XSiEOHzodRgDa62ewUMA9R6f1IB4V
xj05SXtEp9D0ysCl3Mml4V+jbB0dSKi7I7stmowu5A3VrptZzJG+CfaSvr4EXIS/
XnfniGPCOUcCJzf9mqlHCApYxOHUKGxAoONJtHYuNmp1CN7eVsE/GNMwy7/XOTiI
o1jEKD6ddnYKQC1MYlZg
=o+qY
-----END PGP SIGNATURE-----

--qjaKDroskCt6Kqqv--