Re: contrib promotion?

From: "Jim C(dot) Nasby" <jnasby(at)pervasive(dot)com>
To: Marko Kreen <markokr(at)gmail(dot)com>
Cc: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Andrew Dunstan <andrew(at)dunslane(dot)net>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: contrib promotion?
Date: 2006-07-21 20:27:01
Message-ID: 20060721202701.GF83250@pervasive.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Tue, Jul 18, 2006 at 03:37:52PM +0300, Marko Kreen wrote:
> On 7/14/06, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> >I don't see a strong need for moving pgcrypto into core, and there's at
> >least one argument against it: if someone needs a crypto-free version of
> >postgres for use someplace with benighted laws, they would be screwed.
>
> Image of hypothetical evil government is not a thing to base decisions on :)
>
> Although I've tried to develop pgcrypto to be easily mergable into core,
> I don't want to push it myself, the push should come from users.
>
> That said, there is one situation that is badly handled in current
> setup - storing passwords in database. There is md5() function in
> core and everything in /contrib in basically invisible in website
> and official docs. So even PG core devs suggest using md5() for
> this task. But this is inadequate - bruteforcing md5 hash can be
> done pretty easily on todays desktop computers. PostgreSQL itself
> can get away with it only because it regular users cant see the hash.
> But that is not so for ordinary apps.
>
> So I would like either some mention of the more useful/stable modules
> in core docs or a way for contrib modules to become 'official' add-on
> modules (like PL-s are).

This is actually an issue that goes way beyond pgcrypto. I think the
manual should formally mention both /contrib and pgFoundry.org as
someplace to get add-on features. An even better long-term solution
would be something akin to CPAN, but I'm not holding my breath for
that...

> Full merge into core would fix this also, but indeed there is not many
> techical reasons for it. (And editing pg_proc.h is PITA - I'd consider
> it technical reason against it ;)
>
> --
> marko
>
> ---------------------------(end of broadcast)---------------------------
> TIP 6: explain analyze is your friend
>

--
Jim C. Nasby, Sr. Engineering Consultant jnasby(at)pervasive(dot)com
Pervasive Software http://pervasive.com work: 512-231-6117
vcard: http://jim.nasby.net/pervasive.vcf cell: 512-569-9461

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Hannu Krosing 2006-07-21 20:42:36 Re: Transaction Speed and real time database
Previous Message korry 2006-07-21 19:38:16 Re: Loading the PL/pgSQL debugger (and other plugins)