The most recent version of this patch has been added.
Your patch has been added to the PostgreSQL unapplied patches list at:
http://momjian.postgresql.org/cgi-bin/pgpatches
It will be applied as soon as one of the PostgreSQL committers reviews
and approves it.
---------------------------------------------------------------------------
Jeremy Drake wrote:
> On Thu, 25 Jan 2007, Jeremy Drake wrote:
>
> > On Thu, 25 Jan 2007, Jeremy Drake wrote:
> >
> > > I think that an ALTER LANGUAGE OWNER TO is the proper response to these
> > > things, and unless I hear otherwise I will attempt to add this to my
> > > patch.
> >
> > Here is the patch which adds this. It also allows ALTER LANGUAGE RENAME
> > TO for the owner, which I missed before. I would appreciate someone with
> > more knowledge of the permissions infrastructure to take a look at it
> > since I am fairly new to it and may not fully understand its intricacies.
> >
>
> I have refactored the owner checking of languages in the same manner as it
> is for other owned objects. I have changed to using standard permissions
> error messages (aclcheck_error) for the language permissions errors.
>
> I consider this patch ready for review, assuming the permissions rules
> outlined by Tom Lane on -hackers are valid. For reference, here are the
> rules that this patch is intended to implement:
>
> On Wed, 24 Jan 2007, Tom Lane wrote:
>
> > In detail, it'd look something like:
> >
> > * For an untrusted language: must be superuser to either create or use
> > the language (no change from current rules). Ownership of the
> > pg_language entry is really irrelevant, as is its ACL.
> >
> > * For a trusted language:
> >
> > * if pg_pltemplate.something is ON: either a superuser or the current
> > DB's owner can CREATE the language. In either case the pg_language
> > entry will be marked as owned by the DB owner (pg_database.datdba),
> > which means that subsequently he (or a superuser) can grant or deny
> > USAGE within his DB.
> >
> > * if pg_pltemplate.something is OFF: must be superuser to CREATE the
> > language; subsequently it will be owned by you, so only you or another
> > superuser can grant or deny USAGE (same behavior as currently).
>
> The only difference from this is, that when superuser is required, the
> owner of the language is not the superuser who created it, but
> BOOTSTRAP_SUPERUSERID. This is because my interpretation was that the
> "same behavior as currently" took precedence. The current behavior in cvs
> is that languages have no owner, and for purposes where one would be
> needed it is assumed to be BOOTSTRAP_SUPERUSERID.
>
> Is this valid, or should I instead set the owner to GetUserId() in those
> cases?
>
>
> --
> Academic politics is the most vicious and bitter form of politics,
> because the stakes are so low.
> -- Wallace Sayre
Content-Description:
[ Attachment, skipping... ]
>
> ---------------------------(end of broadcast)---------------------------
> TIP 6: explain analyze is your friend
--
Bruce Momjian <[EMAIL PROTECTED]> http://momjian.us
EnterpriseDB http://www.enterprisedb.com
+ If your life is a hard drive, Christ can be your backup. +
---------------------------(end of broadcast)---------------------------
TIP 9: In versions below 8.0, the planner will ignore your desire to
choose an index scan if your joining column's datatypes do not
match
