Re: PGXS: REGRESS_OPTS=--load-language=plpgsql - Mailing list pgsql-hackers

From Tom Lane
Subject Re: PGXS: REGRESS_OPTS=--load-language=plpgsql
Date
Msg-id 28942.1266724570@sss.pgh.pa.us
Whole thread Raw
In response to Re: PGXS: REGRESS_OPTS=--load-language=plpgsql  (Robert Haas <robertmhaas@gmail.com>)
Responses Re: PGXS: REGRESS_OPTS=--load-language=plpgsql
Re: PGXS: REGRESS_OPTS=--load-language=plpgsql
List pgsql-hackers
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.
        regards, tom lane


pgsql-hackers by date:

Previous
From: Robert Haas
Date:
Subject: Re: PGXS: REGRESS_OPTS=--load-language=plpgsql
Next
From: Robert Haas
Date:
Subject: Re: PGXS: REGRESS_OPTS=--load-language=plpgsql