Re: PGXS: REGRESS_OPTS=--load-language=plpgsql
Robert Haas <robertmhaas@gmail.com>
From: Robert Haas <robertmhaas@gmail.com>
To: Tom Lane <tgl@sss.pgh.pa.us>
Cc: David Christensen <david@endpoint.com>, Bruce Momjian <bruce@momjian.us>, "David E. Wheeler" <david@kineticode.com>, Dimitri Fontaine <dfontaine@hi-media.com>, Takahiro Itagaki <itagaki.takahiro@oss.ntt.co.jp>, David Fetter <david@fetter.org>, Euler Taveira de Oliveira <euler@timbira.com>, PG Hackers <pgsql-hackers@postgresql.org>
Date: 2010-02-21T04:08:58Z
Lists: pgsql-hackers
On Feb 20, 2010, at 10:56 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote: > Robert Haas <robertmhaas@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. Exactly. I agree completely. ...Robert