PGXS: REGRESS_OPTS=--load-language=plpgsql
in [PgSql]
|
Prev: testing cvs HEAD - HS/SR - PANIC: cannot make newWAL entries during recovery
Next: Thread safety and libxml2
From: Tom Lane on 21 Feb 2010 12:29 Robert Haas <robertmhaas(a)gmail.com> writes: > On Feb 20, 2010, at 10:56 PM, Tom Lane <tgl(a)sss.pgh.pa.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? regards, tom lane
From: Robert Haas on 21 Feb 2010 13:09 On Sun, Feb 21, 2010 at 12:29 PM, Tom Lane <tgl(a)sss.pgh.pa.us> wrote: > Robert Haas <robertmhaas(a)gmail.com> writes: >> On Feb 20, 2010, at 10:56 PM, Tom Lane <tgl(a)sss.pgh.pa.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 -- Sent via pgsql-hackers mailing list (pgsql-hackers(a)postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
From: Tom Lane on 21 Feb 2010 13:21 Robert Haas <robertmhaas(a)gmail.com> writes: > 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? It will be owned by the bootstrap superuser, so the case is exactly the one that a non-superuser DBA would be faced with. regards, tom lane -- Sent via pgsql-hackers mailing list (pgsql-hackers(a)postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
From: Robert Haas on 21 Feb 2010 13:40 On Sun, Feb 21, 2010 at 1:21 PM, Tom Lane <tgl(a)sss.pgh.pa.us> wrote: > Robert Haas <robertmhaas(a)gmail.com> writes: >> 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? > > It will be owned by the bootstrap superuser, so the case is exactly > the one that a non-superuser DBA would be faced with. Or even a superuser other than the bootstrap superuser, no? I dump out the DB on my 8.4 server and try to reload on 9.0 with --single and it fails because, even though I'm a superuser, I can't replace a language owned by someone else? ....Robert -- Sent via pgsql-hackers mailing list (pgsql-hackers(a)postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
From: Bruce Momjian on 21 Feb 2010 14:25
Tom Lane wrote: > Robert Haas <robertmhaas(a)gmail.com> writes: > > On Feb 20, 2010, at 10:56 PM, Tom Lane <tgl(a)sss.pgh.pa.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. 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? -- Bruce Momjian <bruce(a)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. + -- Sent via pgsql-hackers mailing list (pgsql-hackers(a)postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers |