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

On Sat, Feb 20, 2010 at 6:42 PM, David Christensen <david(at)endpoint(dot)com> wrote:
> In what cases would one be able to meaningfully REPLACE a language, other
> than to not break when encountering an already installed language?  i.e., in
> which cases would this not invalidate functions already written if you were
> changing from trusted to untrusted status or a different call handler, etc.

At the risk of being smart, who cares and why is this our problem?
This question has been asked before, and I can't really figure out
what is behind the asking of it. It is as if someone imagines that
you would install plperl and then come along later and change the
handlers to, say, the plpython handlers, and then complain that your
functions were all broken. But that is obviously stupid, and no one
would do it (or if they did, we would laugh at them).

I think the most likely use of CREATE OR REPLACE FUNCTION is to avoid
an error when creating a language that might already exist. But it
doesn't seem like the only possible use. Perhaps you've done an
in-place upgrade to version 9.0 and you'd like to add an inline
handler, for example.

>  If there is not a meaningful case for the OR REPLACE, and it is just a
> syntactic loophole to allow the errorless recreation of an existing language
> and if the parameters for the CREATE LANGUAGE call indicate identical final
> state, why aren't we free change change the semantics of CREATE LANGUAGE to
> just issue a NOTIFY instead of an error in that case, and only complain if
> there are differences in the call handler, trusted status, etc?

I guess we could do that, but it's inconsistent with the way we handle
other object types, so it doesn't seem as clean to me.

...Robert