On Wed, Mar 5, 2014 at 9:52 AM, Bruce Momjian <br...@momjian.us> wrote:
> On Wed, Mar 5, 2014 at 09:19:33AM -0600, Merlin Moncure wrote:
>> On Wed, Mar 5, 2014 at 8:39 AM, Bruce Momjian <br...@momjian.us> wrote:
>> > So, I am going to ask a back-track question and ask why we can't move
>> > hstore into core.
>> This is exactly the opposite of what should be happening. Now, jsonb
>> might make it into core because of the json precedent but the entire
>> purpose of the extension system is stop dumping everything in the
>> public namespace. Stuff 'in core' becomes locked in stone, forever,
>> because of backwards compatibility concerns, which are IMNSHO, a
>> bigger set of issues than even pg_upgrade related issues. Have we
>> gone through all the new hstore functions and made sure they don't
>> break existing applications? Putting things in core welds your only
>> escape hatch shut.
>> *All* non-sql standard types ought to be in extensions in an ideal world.
> I have seen your opinion on this but there have been enough
> counter-arguments that I am not ready to head in that direction.
The only counter argument given is that this will prevent people from
being able to use extensions because they A: can't or won't install
contrib packages or B: are too stupid or lazy to type 'create
extension json'. Note I'm discussing 'in core extension vs in core
built in'. 'out of core extension' loosely translates to 'can't be
used by the vast majority of systems.
Most corporate IT departments (including mine) have a policy of only
installing packages through the operating system packaging to simplify
management of deploying updates. Really strict companies might not
even allow anything but packages supplied by a vendor like redhat
(which in practice keeps you some versions back from the latest).
Now, if some crappy hosting company blocks contrib I don't believe at
all that this should drive our project management decisions.
Postgresql is both a database and increasingly a development language
platform. Most good stacks have a system (cpan, npm, etgc) to manage
the scope of the installed runtime and it's a routine and expected
exercise to leverage that system.
Sent via pgsql-hackers mailing list (email@example.com)
To make changes to your subscription: