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

Поиск
Список
Период
Сортировка
От Robert Haas
Тема Re: PGXS: REGRESS_OPTS=--load-language=plpgsql
Дата
Msg-id 7960001991174734380@iso-8859-1msgid
обсуждение исходный текст
Ответ на Re: PGXS: REGRESS_OPTS=--load-language=plpgsql  (Tom Lane <tgl@sss.pgh.pa.us>)
Список 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


В списке pgsql-hackers по дате отправления:

Предыдущее
От: Pavel Stehule
Дата:
Сообщение: Plans for 9.1, Grouping Sets, disabling multiqueries, contrib module for string, plpgpsm, preload dictionaries
Следующее
От: Robert Haas
Дата:
Сообщение: getting to beta