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

From Robert Haas
Subject Re: PGXS: REGRESS_OPTS=--load-language=plpgsql
Date
Msg-id 603c8f071002191034y647b7102nb09e375c26c9d5e7@mail.gmail.com
Whole thread Raw
In response to Re: PGXS: REGRESS_OPTS=--load-language=plpgsql  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: PGXS: REGRESS_OPTS=--load-language=plpgsql
Re: PGXS: REGRESS_OPTS=--load-language=plpgsql
List pgsql-hackers
On Thu, Feb 18, 2010 at 11:38 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
> Takahiro Itagaki <itagaki.takahiro@oss.ntt.co.jp> writes:
>> David Fetter <david@fetter.org> wrote:
>>> support both pre-9.0 and post-9.0 PostgreSQLs.  David Wheeler has
>>> suggested that we special-case PL/pgsql for 9.0 and greater, as it's
>>> in template0, where those tests are based.
>
>> +1 for the CREATE LANGUAGE IF NOT EXISTS behavior.
>
>> The regression test in the core is targeting only its version,
>> but some external projects have version-independent tests.
>
> I think it's more like "are under the fond illusion that their tests are
> version-independent".  Are we going to back out the next incompatible
> change we choose to make as soon as somebody notices that it breaks a
> third-party test case?  I don't think so.  Let me point out that
> choosing to install plpgsql by default has already broken "--single"
> restore of practically every pg_dump out there.  Nobody batted an eye
> about that.  Why are we suddenly so concerned about its effects on
> unnamed test suites?

I am still of the opinion that changing this was a bad idea for
exactly this reason.  We could perhaps ameliorate this problem by
implementing CREATE OR REPLACE for languages and emitting that
instead; then the command in the dump would be a noop.

...Robert


pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: ALTER ROLE/DATABASE RESET ALL versus security
Next
From: David Fetter
Date:
Subject: Re: PGXS: REGRESS_OPTS=--load-language=plpgsql