Re: [PATCH] Store Extension Options - Mailing list pgsql-hackers

On Thu, Mar 13, 2014 at 12:47 AM, Simon Riggs <simon@2ndquadrant.com> wrote:
> On 13 March 2014 02:14, Robert Haas <robertmhaas@gmail.com> wrote:
>>> I'm not sure why this is being blocked. This is a community
>>> contribution that seeks to improve everybody's options. Blocking it
>>> does *nothing* to prevent individual extensions from providing
>>> table-level options - we give them freedom to do whatever the hell
>>> they want. Validation is a pipe dream, not *ever* an achievable
>>> reality. Blocking is just exercise of a veto for nobody's gain.
>>
>> Unsurprisingly, I don't agree with any of that.
>
> The point is that execising a veto here is irrelevant. Blocking this
> patch does *nothing* to prevent extensions from adopting per-table
> options. All that is happening is that a single, coherent mechanism
> for such options is being blocked. Blocking this is like trying to
> block rain. We can all pretend the blocking viewpoint has succeeded,
> but all it does is to bring Postgres core into disrepute. I have often
> heard that from others that this is a business opportunity, not a
> problem. If that is true, its not because we didn't try to act for the
> good of all.

It is very true that there are other ways for extensions to manage
per-table options.  In my mind, that's another reason NOT to throw
open the door to unrestricted use of reloptions to store whatever
anyone wants to throw in there, but rather to wait until we have a
sound and well-thought-out design that we're comfortable with our
ability to support and extend into the indefinite future.

The bottom line here is that, as in previous years, there are a
certain number of people who show up near the end of CF4 and are
unhappy that some patch didn't get committed.  Generally, they allege
that (1) there's nothing wrong with the patch, (2) if there is
something wrong with the patch, then it's the fault of the people
objecting for not volunteering to fix it, and (3) that if the patch
isn't committed despite the objections raised, it's going to be
hideously bad for PostgreSQL.  Josh Berkus chose to put his version of
this rant on his blog:

http://www.databasesoup.com/2014/02/why-hstore2jsonb-is-most-important.html

But the reality is that most of the patches we reject are in my
opinion rejected for good reasons (though some are rejected for bad
reasons); that most of the ones that really matter emerge for a later
release in greatly improved form; and that the product is better
overall of for those delays.  Because on projects where people are
quick to commit irrevocably to insufficiently-scrutinized design
decisions, huge amounts of time and energy get spent digging out from
under those bad decisions; or else nobody fixes it and the product
just stinks.  So, in my opinion, the time and care that we take to get
things right is a feature, not a bug.  Your mileage may, of course,
vary.

-- 
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company