Re: Extension Templates S03E11 - Mailing list pgsql-hackers

From Stephen Frost
Subject Re: Extension Templates S03E11
Date
Msg-id 20131211195641.GG2543@tamriel.snowman.net
Whole thread Raw
In response to Re: Extension Templates S03E11  (Dimitri Fontaine <dimitri@2ndQuadrant.fr>)
List pgsql-hackers
Dimitri,

* Dimitri Fontaine (dimitri@2ndQuadrant.fr) wrote:
> Stephen Frost <sfrost@snowman.net> writes:
> > The extra catalog tables which store SQL scripts in text columns is one
> > of my main objections to the as-proposed Extension Templates.  I view
> > those scripts as a poor man's definition of database objects which are
> > defined properly in the catalog already.
>
> I have a very hard time to understand this objection.
>
> PL/SQL functions are just a SQL script stored as-is in the catalogs.
> That applies the same way to any other PL language too, with scripts
> stored as-is in the catalogs in different languages.

Sure- but in those cases only the actual function (which is, by
definition, for an *interpreted* language..) is stored as text, not
the definition of the function (eg: the CREATE FUNCTION statement), nor
all of the metadata, dependency information, etc.  Also, what you're
proposing would result in having *both* in the same catalog- the
canonical form defined in pg_proc and friends, and the SQL text blob in
the extension template catalog and I simply do not see value in that.

> So while I hear your objection to the "script in catalog" idea Stephen,
> I think we should move forward. We don't have the luxury of only
> applying patches where no compromise has to be made, where everyone is
> fully happy with the solution we find as a community.

I understand that you wish to push this forward regardless of anyone's
concerns.  While I appreciate your frustration and the time you've spent
on this, that isn't going to change my opinion of this approach.

> >  The other big issue is that
> > there isn't an easy way to see how we could open up the ability to
> > create extensions to non-superusers with this approach.
>
> The main proposal here is to only allow the owner of a template to
> install it as an extension. For superusers, we can implement the needed
> SET ROLE command automatically in the CREATE EXTENSION command.
>
> Is there another security issue that this “same role” approach is not
> solving? I don't think so.

This isn't kind, and for that I'm sorry, but this feels, to me, like a
very hand-wavey "well, I think this would solve all the problems" answer
to the concerns raised.  I can't answer offhand if this would really
solve all of the issues because I've not tried to implement it or test
it out, but I tend to doubt that it would.
Thanks,
    Stephen

pgsql-hackers by date:

Previous
From: Josh Berkus
Date:
Subject: Re: autovacuum_work_mem
Next
From: Kevin Grittner
Date:
Subject: Re: Reference to parent query from ANY sublink