Re: in-catalog Extension Scripts and Control parameters (templates?)

Hi,

Thanks you for testing and reporting those strange bugs, I should be
able to fix them by Tuesday at the earliest.

Heikki Linnakangas <hlinnakangas(at)vmware(dot)com> writes:
> create template for extension sslinfo version '1.0' with (schema public) as
> $$ DO EVIL STUFF $$;

What you're saying is that we should restrict the capability to
superusers only, where I didn't think about those security implications
before and though that it wouldn't be a necessary limitation.

I will add the usual superuser() checks in the next version of the
patch.

> Documentation doesn't build, multiple errors. In addition to the reference
> pages, there should be a section in the main docs about these templates.

I really would like for a simpler setup to build documentation on my OS
of choice, and realize that's no excuse. Will clean that up in next
version of the patch.

>> postgres=# create template for extension myextension version '1.0' with () as 'foobar';
>> CREATE TEMPLATE FOR EXTENSION
>> postgres=# create extension myextension;
>> ERROR: syntax error at or near "foobar"
>> LINE 1: create extension myextension;
>> ^
>
> Confusing error message.

Do we need to compute a different error message when applying the script
from a template or from a file on-disk? Also please keep in mind that
those error messages are typically to be seen by the extension's author.

>> postgres=# create template for extension myextension version '1.0' with () as $$create table foobar(i int4) $$;
>> CREATE TEMPLATE FOR EXTENSION
>> postgres=# create extension myextension;
>> CREATE EXTENSION
>> postgres=# select * from foobar;
>> ERROR: relation "foobar" does not exist
>> LINE 1: select * from foobar;
>> ^
>
> Where did that table go?

Well that's not the answer I wanted to make, but:

select c.oid, relname, nspname
from pg_class c join pg_namespace n on n.oid = c.relnamespace
where relname ~ 'foobar';
oid | relname | nspname
-------+---------+-------------
41412 | foobar | 1.0
(1 row)

> Ah, here... Where did that " 1.0" schema come from?

I need to sort that out. Didn't have that problem in my tests (included
in the regression tests), will add your test case and see about fixing
that bug in the next version of the patch.

>> postgres=> create template for extension myextension version '1.0' with
>> (schema public) as $$ create function evilfunc() returns int4 AS
>> evilfunc' language internal; $$;
>> CREATE TEMPLATE FOR EXTENSION
>> postgres=> create extension myextension version '1.0';ERROR: permission denied for language internal
>> postgres=> drop template for extension myextension version '1.0';
>> ERROR: extension with OID 16440 does not exist
>
> Something wrong with catalog caching.

Or something wrong with dependencies maybe… will have a look at that
too, and add some regression tests.

>> $ make -s install
>> /usr/bin/install: cannot stat `./hstore--1.0.sql': No such file or directory
>> make: *** [install] Error 1
>
> Installing hstore fails.

Works for me. Anyway that part was to show up how we could have been
managing the hstore 1.1 update in the past, I don't intend for it to get
commited unless specifically asked to do so.

I guess I should now remove hstore changes from the patch now, and will
do so in the next version of the patch.

> If we check for an existing extension at CREATE, should also check for that
> in ALTER ... RENAME TO.

Indeed. Will fix that too.

> Also:
> pg_dump does not dump the owner of an extension template correctly.

Will look into that too.

Thanks for your reviewing and testing, sorry to have missed those bugs.
The new version of the patch, early next week, will include fixes for
all of those and some more testing.

Regards,
--
Dimitri Fontaine
http://2ndQuadrant.fr PostgreSQL : Expertise, Formation et Support