Re: Policy on pulling in code from other projects?

From: Peter van Hardenberg <pvh(at)pvh(dot)ca>
To: Andrew Dunstan <andrew(at)dunslane(dot)net>
Cc: "Joshua D(dot) Drake" <jd(at)commandprompt(dot)com>, pgsql-hackers(at)postgresql(dot)org
Subject: Re: Policy on pulling in code from other projects?
Date: 2011-08-10 01:00:42
Message-ID: CAAcg=kWRkA+Cv8XBawMhQ2VhSwVbK9VR+OR2Emh8rY0Xh4XY4Q@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Sat, Jul 23, 2011 at 3:39 AM, Andrew Dunstan <andrew(at)dunslane(dot)net> wrote:

>
> 1. I think the proposed use is of very marginal value at best, and
> certainly not worth importing an external library for.
>
>
Now that I've seen two people who seem to think that this is not an
important feature I'll wade in and respond to this idea.

I think it's very easy to doubt the value of a definitively recognizable
string that represents a postgres database when you don't have a
heterogenous environment with more than a hundred thousand applications of
all types in it. To make matters worse, as language support on that platform
continues to widen beyond its humble beginnings, there isn't a standard
across those languages for what constitutes a postgres URL. This is the
current situation at Heroku, where we currently run ~150,000 individual
databases on our infrastructure as well as a variety of other databases such
as MySQL, Redis, Mongo, Couch, Riak, Cassandra, &c.

To head off the most obvious criticism, we aren't using connection strings
in our system because there isn't any reasonable way to recognize them. A PG
conninfo string is just a set of key value pairs with no dependably present
signifier. This is why almost every database library from Ruby to Python to
Java takes some form of a URL with a protocol called "postgres" in it in
order to help select which driver to use.

Further, support (and syntax!) for the more esoteric connection parameters
varies from library to library as well as between languages. A good spec by
the project would go a long way in resolving this, and I can at least be
confident that we could get it adopted very quickly by all three of the
Ruby-community Postgres libraries.

In conclusion, this is a serious operational concern for me and my team and
I will be personally dealing with fires caused by this for years to come
regardless of the outcome of this thread.

Best,
-pvh

--
Peter van Hardenberg
Department of Data
Heroku
"Everything was beautiful, and nothing hurt." -- Kurt Vonnegut

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Noah Misch 2011-08-10 06:45:37 Re: augmenting MultiXacts to improve foreign keys
Previous Message Tom Lane 2011-08-10 00:35:38 Re: Reduced power consumption in autovacuum launcher process