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

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Bruce Momjian <bruce(at)momjian(dot)us>
Cc: Robert Haas <robertmhaas(at)gmail(dot)com>, David Christensen <david(at)endpoint(dot)com>, "David E(dot) Wheeler" <david(at)kineticode(dot)com>, Dimitri Fontaine <dfontaine(at)hi-media(dot)com>, Takahiro Itagaki <itagaki(dot)takahiro(at)oss(dot)ntt(dot)co(dot)jp>, David Fetter <david(at)fetter(dot)org>, Euler Taveira de Oliveira <euler(at)timbira(dot)com>, PG Hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: PGXS: REGRESS_OPTS=--load-language=plpgsql
Date: 2010-02-21 22:16:54
Message-ID: 29091.1266790614@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Bruce Momjian <bruce(at)momjian(dot)us> writes:
> Tom Lane wrote:
>> Attached is a draft patch (no doc changes) that implements CREATE OR
>> REPLACE LANGUAGE

> How is pg_migrator affected by this? It always loads the the dump as
> the super-user. How will the pg_dump use CREATE OR REPLACE LANGUAGE?

pg_dump would issue "CREATE OR REPLACE LANGUAGE plpgsql" which would
succeed just fine, since it'd be issued by a superuser.

I think the potential downsides of that are significantly smaller than
having a special case that excludes plpgsql altogether --- for one
example, it would still succeed in a custom installation that had been
changed so that plpgsql wasn't installed by default.

BTW, another problem I just noticed with the current kluge is that it
fails to transfer any nondefault permissions that might have been
attached to plpgsql.

regards, tom lane

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Andres Freund 2010-02-21 23:43:26 Re: pgsql: Speed up CREATE DATABASE by deferring the fsyncs until after
Previous Message Tom Lane 2010-02-21 22:11:16 Re: PGXS: REGRESS_OPTS=--load-language=plpgsql