Re: PGXS: REGRESS_OPTS=--load-language=plpgsql

Tom Lane wrote:
> David Christensen <david(at)endpoint(dot)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.

Yea, I did read it, but I was just unclear how adding OR REPLACE wasn't
just moving the hack to another location, and because there was so much
discussion about OR REPLACE, it felt like we were designing the feature,
which is something we don't want to be doing now.

--
Bruce Momjian <bruce(at)momjian(dot)us> http://momjian.us
EnterpriseDB http://enterprisedb.com
PG East: http://www.enterprisedb.com/community/nav-pg-east-2010.do
+ If your life is a hard drive, Christ can be your backup. +