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

On Sun, Feb 21, 2010 at 12:29 PM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> Robert Haas <robertmhaas(at)gmail(dot)com> writes:
>> On Feb 20, 2010, at 10:56 PM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
>>> 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.
>
> Attached is a draft patch (no doc changes) that implements CREATE OR
> REPLACE LANGUAGE following the semantics used in CREATE OR REPLACE
> FUNCTION, namely that in addition to whatever privileges you need to
> do the CREATE, you need to be owner of the existing entry if any;
> and the recorded ownership and permissions don't change.  It's not bad
> at all --- net addition of 40 lines.  So if we want to go at it this
> way, it's certainly feasible.
>
> I've got mixed feelings about the ownership check.  If you get past
> the normal CREATE LANGUAGE permission checks, then either you are
> superuser, or you are database owner and you are trying to recreate
> a language from a pg_pltemplate entry with tmpldbacreate true.
> So it would fail only for a database owner who's trying to do
> C.O.R.L. on a superuser-installed language.  Which arguably is a case
> we ought to allow.  On the other hand, the case where not throwing an
> error would really matter is in trying to do pg_restore --single, and
> in that case even if we allowed the C.O.R.L. it would still spit up on
> the ALTER LANGUAGE OWNER that pg_dump is presumably going to emit right
> afterwards (except if using --no-owner, I guess).  So I'm not sure
> we'd really be gaining much by omitting the ownership check, and it
> would certainly be less consistent with other C.O.R. commands if we
> don't apply such a check.
>
> Comments?

Well, I'm a big fan of CREATE OR REPLACE anything so I like the patch
regardless of whether it solves the current problem, but having said
that, I'm not clear on whether it does in fact solve the current
problem. When PL/pgsql is installed by default, is it going to end up
owned by the DB owner, or might it end up owned by the superuser?

If you end up applying this you might take the to fix up the gram.y
comment a little more thoroughly: CREATE [OR REPLACE] [TRUSTED]
[PROCEDURAL] LANGUAGE; DROP [PROCEDURAL] LANGUAGE.

...Robert