Re: PGXS: REGRESS_OPTS=--load-language=plpgsql - Mailing list pgsql-hackers

From Tom Lane
Subject Re: PGXS: REGRESS_OPTS=--load-language=plpgsql
Date
Msg-id 25356.1266713975@sss.pgh.pa.us
Whole thread Raw
In response to Re: PGXS: REGRESS_OPTS=--load-language=plpgsql  (David Christensen <david@endpoint.com>)
Responses Re: PGXS: REGRESS_OPTS=--load-language=plpgsql
List pgsql-hackers
David Christensen <david@endpoint.com> writes:
> On Feb 20, 2010, at 5:16 PM, Bruce Momjian wrote:
>> If you implement #1, why would you have pg_dump issue CREATE OR
>> REPLACE LANGUAGE?  We don't do the "OR REPLACE" part for any other
>> object I can think of, so why would pg_dump do it for languages by
>> default?

> In what cases would one be able to meaningfully REPLACE a language,  
> other than to not break when encountering an already installed  
> language?

I'm getting the distinct impression that Bruce didn't read yesterday's
portion of this thread...

The proposal that I had in mind was to have pg_dump use OR REPLACE
only when emitting a parameterless CREATE LANGUAGE.  This would
guarantee that both the desired new language definition and any
pre-existing one that it could replace would be exactly like the
pg_pltemplate entry for the language.  The only risk is that the
restore would force the language's ownership and permissions to be
what they'd been in the source database, which might possibly not
be desirable.  Then again it might be desirable; it's really hard
to decide that without a specific scenario in mind.
        regards, tom lane


pgsql-hackers by date:

Previous
From: Dave Page
Date:
Subject: Re: scheduler in core
Next
From: "Joshua D. Drake"
Date:
Subject: Re: scheduler in core