Re: Segmentation fault using digest from pg_crypto - Mailing list pgsql-hackers

From Bruce Momjian
Subject Re: Segmentation fault using digest from pg_crypto
Date
Msg-id 200711110345.lAB3jIv15903@momjian.us
Whole thread Raw
In response to Re: Segmentation fault using digest from pg_crypto  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: Segmentation fault using digest from pg_crypto  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-hackers
Tom Lane wrote:
> Bruce Momjian <bruce@momjian.us> writes:
> > Tom Lane wrote:
> >> If you don't re-run a contrib module's sql script then you don't get any
> >> new functions that may have been added to the module.  So I think the
> >> real issue here is that we ought to deprecate the idea of skipping that
> >> step, period.
> 
> > The good news is that the scripts have CREATE OR REPLACE function so it
> > would clean up everything to match the library you just installed.
> 
> Hmm ... now that you mention it: some of them do, some of them don't.
> And some of them wrap the whole script in BEGIN/COMMIT, which means that
> a conflict against existing definitions would prevent any new
> definitions from being added.
> 
> Seems like maybe we need an explicit project policy that contrib scripts
> should be able to overwrite an existing older installation properly;
> maybe with some error reports, but not failing outright.
> 
> If so, someone will have to do the legwork of really making that happen
> ... any volunteers?

I have cleaned up the contrib install/uninstall to be more consistent,
used CREATE OR REPLACE function consisently, and removed transaction
blocks.

--  Bruce Momjian  <bruce@momjian.us>        http://momjian.us EnterpriseDB
http://postgres.enterprisedb.com
 + If your life is a hard drive, Christ can be your backup. +


pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Refactor parse_type.c's lookup API?
Next
From: Bruce Momjian
Date:
Subject: Re: Segmentation fault using digest from pg_crypto