|From:||Dimitri Fontaine <dimitri(at)2ndQuadrant(dot)fr>|
|To:||Stephen Frost <sfrost(at)snowman(dot)net>|
|Cc:||Jeff Davis <pgsql(at)j-davis(dot)com>, Peter Eisentraut <peter_e(at)gmx(dot)net>, Alvaro Herrera <alvherre(at)2ndquadrant(dot)com>, Boszormenyi Zoltan <zb(at)cybertec(dot)at>, Thom Brown <thom(at)linux(dot)com>, PostgreSQL Hackers <pgsql-hackers(at)postgresql(dot)org>|
|Subject:||Re: Extension Templates S03E11|
|Views:||Raw Message | Whole Thread | Download mbox | Resend email|
Stephen Frost <sfrost(at)snowman(dot)net> writes:
> We already have other 'template' objects in the system and I'm not
> excited about the confusion. This also applies to 'CreateTemplate',
> 'CreateTemplateTupleDesc', right down to 'template.h' and 'template.c'.
The current code is made to expose the notion of a template and only
implements one kind of template, for extensions. Still the
ProcessUtility hooking has been made so as to make it easy adding new
Given that I haven't seen any other template idea in the years I've been
contributing to PostgreSQL other than the FTS template, and that I'm
seeing no other candidate, I took the arbitrary decision not to open the
sources more than that to the idea of other kinds of templates.
We could of course have a 50 lines templates.c file that calls into an
extension_template.c file for the meat of the implementation if that's
prefered by the project.
Just tell me about that, it's not in the attached patch.
> Attached is a patch against v16 which fixes up a few documentation
> issues (I'm pretty sure extension templates and aggregates are
> unrelated..), and points out that there is zero documentation on these
> new catalog tables (look for 'XXX' in the patch) along with a few
> other areas which could use improvement.
I merged your patch in, rebased against master, fixed some more typos I
found, and filled in the gaps you found in the docs. Version 17 of the
patch is attached to that email, passes `make check`.
ENOTIME for building docs, will do tomorrow, I though you might
appreciate an update meanwhile (and with some luck docs still build
The other main point that will change the current code is dealing with
superusers and security concerns. Baring objections, I'm going to
implement a variation of what I did propose in the thread:
When a superuser CREATE EXTENSION against a template that has been
provided by a non-privileged user, automatically SET ROLE to that user
before doing so, avoiding escalation privileges.
If that's not what the superuser intended, then it still is possible for
him to ALTER TEMPLATE FOR EXTENSION … OWNER TO himself beforehand.
http://2ndQuadrant.fr PostgreSQL : Expertise, Formation et Support
|Next Message||Atri Sharma||2013-11-27 17:35:21||Re: Status of FDW pushdowns|
|Previous Message||Tom Lane||2013-11-27 17:30:37||Re: lock on object is already held|