Robert Haas <robertmh...@gmail.com> writes: > I think the most likely use of CREATE OR REPLACE [LANGUAGE] 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.
Given the existing semantics of CREATE LANGUAGE, nothing at all would happen when replacing a language that has a pg_pltemplate entry, because that overrides all the command's options. However, I think CORL has potential use for developers working on a non-core language implementation: they could use it to add an inline handler, for example, without losing the function definitions they already have loaded. Admittedly that's a pretty thin use-case. However, I intensely dislike the line of thought that says "let's take shortcuts because nobody is going to use this except for one specific use-case". There is a very clear set of behaviors that CORL ought to have given the precedents of our other COR commands. If we don't make it do things that way then we are going to surprise users, and we are also going to paint ourselves into a corner because we won't be able to fix it later without creating compatibility gotchas. regards, tom lane -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers