Date: Wed, 1 Jul 2020 19:00:07 -0400
From: Stephen Frost <sfrost@snowman.net>
To: Tom Lane <tgl@sss.pgh.pa.us>
Cc: Andrew Dunstan <andrew.dunstan@2ndquadrant.com>,
	Noah Misch <noah@leadboat.com>, Robert Haas <robertmhaas@gmail.com>,
	Chapman Flack <chap@anastigmatix.net>,
	Peter Eisentraut <peter.eisentraut@2ndquadrant.com>,
	Joe Nelson <joe@begriffs.com>,
	"pgsql-hackers@postgresql.org" <pgsql-hackers@postgresql.org>
Subject: Re: POC: rational number type (fractions)
Message-ID: <20200701230007.GC3125@tamriel.snowman.net>
References: <20200208042554.GE42864@begriffs.com>
 <0e2422da-953b-6b96-1900-f67c7e5e3307@2ndquadrant.com>
 <5EC3031C.6020105@anastigmatix.net>
 <20552.1589840076@sss.pgh.pa.us>
 <CA+TgmobheOusVXxzKX6y3NaHYdTuoRFEaff6DcYMOEBgjY8gBQ@mail.gmail.com>
 <20200522055332.GA1296415@rfd.leadboat.com>
 <57d0e68d-2706-60a3-f020-ba4c8fd4b64b@2ndQuadrant.com>
 <20200701203246.GX3125@tamriel.snowman.net>
 <812520.1593643251@sss.pgh.pa.us>
MIME-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha512;
	protocol="application/pgp-signature"; boundary="VV5cy58oktor8I5H"
Content-Disposition: inline
In-Reply-To: <812520.1593643251@sss.pgh.pa.us>
User-Agent: Mutt/1.5.24 (2015-08-30)
Precedence: bulk


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

Greetings,

* Tom Lane (tgl@sss.pgh.pa.us) wrote:
> Stephen Frost <sfrost@snowman.net> writes:
> > I disagree with this and instead lean more towards the side that Robert
> > and Jeff were taking in that this would be a useful extension and
> > something we should consider including in core.  I disagree with Tom and
> > Noah, specifically because, if we add this capability then I see our
> > potential use-cases as increasing and therefore getting more individuals
> > interested in working with us- to potentially include new contributors
> > and possibly committers.
>=20
> FWIW, I'm entirely in favor of having this available as an extension.
> But I'm not in favor of it being in core.  I'm afraid it will end up
> like the geometric types, i.e. a backwater of not-very-good code that
> gets little love because it's not in line with the core competencies
> of a bunch of database geeks.  If it's a separate project, then we
> could hope to attract interest from people who know the subject matter
> better but would never dare touch the PG backend in general.  There's
> also the whole project-management issue that we have finite resources
> and so we can *not* afford to put every arguably-useful feature in core.

The issue that you highlight regarding geometric types is really that we
simply refuse to punt things from core, ever, and that's not a
reasonable position to take for long-term sanity.  On the flip side,
it's ridiculously rare for an extension to have any kind of real
life as an independent project- yes, there's one big exception (PostGIS)
because it's simply ridiculously useful, and a few other cases
where one company/individual or another funds the work of a particular
extension because they need it for whatever, but by and large,
extensions outside of PG simply don't thrive as independent projects.

There's various potential reasons for that, from being hard to find, to
being hard to install and work with, to the fact that we don't have a
centralized extension system (PGXN isn't really endorsed at all by
core... and I don't really think it should be), and our general
extension management system isn't particularly great anyway.

The argument that we simply aren't able to ever extend the surface area
of the database server beyond simple types because anything else
requires specialized knowledge that general database hackers don't have
implies that every committee/maintainers must be a general database
hacker that knows all kinds of stuff about the innards of the kernel,
but that isn't the case, even among our committers today- different
folks have confidence working in different areas and that's an entirely
good thing that allows us to increase our pool of resources while not
expecting folks to be complete generalists.  How do we build on that,
while not ending up with code getting dumped on us and then left with us
to maintain?  That's the problem we need to solve, and perhaps other
projects can give us insight, but I certainly won't accept that we
simply must accept some glass ceiling regardless of how many people want
to help us move forward- let's find a sensible way for them to help us
move forward while not increasing drag to the point that we fall out of
the sky.

Thanks,

Stephen

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

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

iQIcBAEBCgAGBQJe/RV3AAoJEO1sijiDR2RVhwwP/00VNbOCWQrHPKk7caTQ/WaJ
8GmAi6es3ncSOONyo/P5GC4T8SLYV3y+eNpb/dQ1KqNFKebY7NofkeBp5bjinZfz
qDybyyhVTlewF5fgvGaqoKtYBukD6UqHrVYj+QWb4gQHeyeEcjKB77mKpk9VgJaC
OBAhsV5zvxLArRHPYm9f1gfmNrqNH7EkbL7xS39go1Zmw/zG0kQLvfiFXhtnnMwp
6nLCuc0AOATTQqmOd7YMRY1wEVl64w0AHBz2hqXkvly4UGJQzjlyxuG/Ci9sCL28
8TAf+pXddgEnzH0e2Q8/FfUFmrKyhCb+/fIyELA1gDG+UPme13Nyzq/19YJeLI4G
BSTT1XmwKp6etsGru5fTJb+B450/4HSElYAWLxe2eZfkPG7P6iA8rqRfjXWkAOO5
LeRPlYlJvA54d7M0+c7gFEVBNmJy+AMT402v+r5kerly67iNmTq0cnWEVe6EiFw7
wFCQu1Ewe/afz0mr3I1wQNCIrlheH7FBNoDwd9agfwzYxvIw1W7PswJLbfBZJwWw
bG8EpdZq+jwyjz5qFe+JjtY7i30cp+8OAfTuagjAhazUyzkGIdD9c+1tgqeD9WBZ
wykMcBNshli7SHtmpczNR71zldX/ljbomxXx/2gBSXslfq0wY1ti7is7YsZFq9IX
xw/ljVqfhCE9W66KKUMy
=RAT3
-----END PGP SIGNATURE-----

--VV5cy58oktor8I5H--