On Sat, Feb 20, 2010 at 6:42 PM, David Christensen <da...@endpoint.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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
