|From:||Dimitri Fontaine <dimitri(at)2ndQuadrant(dot)fr>|
|To:||Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>|
|Cc:||PostgreSQL Hackers <pgsql-hackers(at)postgresql(dot)org>|
|Subject:||Re: in-catalog Extension Scripts and Control parameters (templates?)|
|Views:||Raw Message | Whole Thread | Download mbox|
Please find attached a preliminary patch following the TEMPLATE ideas,
and thanks in particular to Tom and Heikki for a practical design about
how to solve that problem!
Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> writes:
>> - Extension Scripts are now stored in the catalogs, right?
> Only for these new-style thingies. I am not suggesting breaking the
> existing file-based implementation, only offering a parallel
> catalog-based implementation too. We'd have to think about what to do
> for name collisions --- probably having the catalog entry take
> precedence is okay, but is there an argument for something else?
The attached patch is implementing TEMPLATEs only for these new-style
thingies. Conflicts are checked at template creation time, and at create
extension time we do the file system lookup first, so that's the winner.
>> [ need separate catalogs for install scripts and update scripts ]
You'll find the 3 of them in the attached unfinished patch (install,
> Actually, given the text search precedent, I'm not sure why you're so
> against TEMPLATE.
So I called them TEMPLATE and I tried hard to leave that term open to
other uses. As a result the main syntax is
CREATE TEMPLATE FOR EXTENSION …
ALTER TEMPLATE FOR EXTENSION …
DROP TEMPLATE FOR EXTENSION …
No new keyword has been added to the parser in the making of this patch.
You'll find some usage examples in the regression tests part of the
patch, and the new commands have received the very minimum documentation
coverage. I intend to fill in the docs some more before calling it ready
for commit, of course.
I'm at a point where I need feedback before continuing though, and I
think Tom is in the best position to provide it given the previous
>> The $2.56 question being what would be the pg_dump policy of the
>> "extension templates" objects?
> The ones that are catalog objects, not file objects, should be dumped
> I think.
So, the current version of the patch has no support for pg_dump and psql
yet, and most ALTER commands in the grammar are not yet implemented. In
the lacking list we can also add ALTER … OWNER TO / RENAME and COMMENT,
both for the new catalog objects and the extension to be created from
I think we could transfer the COMMENT on the template from the
pg_extension_control (so that you can change the comment at upgrade) to
the extension, but wanted to talk about that first. The alternative is
to simply add a comment column to the pg_extension_control catalog,
along with a grammar rule to get the information from the commands.
http://2ndQuadrant.fr PostgreSQL : Expertise, Formation et Support
|Next Message||Bruce Momjian||2013-01-08 00:46:46||Re: A very small typo in the comment|
|Previous Message||Robert Haas||2013-01-07 22:37:13||Re: psql \l to accept patterns|