Horton
Menu

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

Bruce Momjian <bruce@momjian.us>

View thread
From: Bruce Momjian <bruce@momjian.us>
To: Tom Lane <tgl@sss.pgh.pa.us>
Cc: Robert Haas <robertmhaas@gmail.com>, David Christensen <david@endpoint.com>, "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-22T00:23:34Z
Lists: pgsql-hackers 
Tom Lane wrote:
> Bruce Momjian <bruce@momjian.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.

Are we doing this just for plpgsql in pg_dump?

> 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.

Well, I assumed the permissions would still come, just not the CREATE
LANGUAGE, but now that I think about it you might be right.

-- 
  Bruce Momjian  <bruce@momjian.us>        http://momjian.us
  EnterpriseDB                             http://enterprisedb.com
  PG East:  http://www.enterprisedb.com/community/nav-pg-east-2010.do
  + If your life is a hard drive, Christ can be your backup. +