Extension Facility

On Jul 22, 2009, at 11:46 AM, Dimitri Fontaine wrote:

Here are from memory the problems we don't have a solution for yet:
- how to give user the ability to install the extension's objects in
another schema than the pg_extension default one

Was that not a part of your original proposal, or the ensuing
discussion? Hrm, perhaps not. So I suggest that we take your proposed
syntax:

create extension foo ...

And just allow it to take a schema-qualified argument like any other
SQL command:

create extension myschema.foo ...

- how to provide extension author a way to have major PG version
dependant code without having to implement and maintain a specific
function in their install.sql file

For a lot of extensions this may not be necessary. So I don't think
I'd hold up an initial implementation waiting for this to be figured
out. My $0.02.

Best,

David

Hi,

"David E. Wheeler" <david@kineticode.com> writes:

On Jul 22, 2009, at 11:46 AM, Dimitri Fontaine wrote:

- how to give user the ability to install the extension's objects in
another schema than the pg_extension default one

And just allow it to take a schema-qualified argument like any other SQL
command:

create extension myschema.foo ...

The problem is to allow extension code to refer to other extension code
without security problems related to search_path: in short, as an
extension author you want to be able to schema qualify your function
calls or even the PROCEDURE attached to your operators.

Now how to be able to refer to the extension schema in the install.sql
file if user is allowed to install where he wants?

Easy answer for first version: don't allow user to install extension in
another place than what we think will better suit him, and that's the
new schema pg_extension, which always lies just before pg_catalog in the
search_path.

- how to provide extension author a way to have major PG version dependant
code without having to implement and maintain a specific function in
their install.sql file

For a lot of extensions this may not be necessary. So I don't think I'd hold
up an initial implementation waiting for this to be figured out. My $0.02.

Yes. I came up with the beginning of something (major version dependant
additional install.sql files) but then you need to control ordering, so
maybe pre and post install files with major version dependant
derivatives. "Over engineered" is certainly the comment I'll hear about
it.

Regards,
--
dim

P.S: the best way to help me with the extension stuff as of now would be
to confirm the syntax proposal (separating extension metadata creation
from installation step) is sound for you, and possibly giving hint about
the proposed completion plan up in this thread.

http://archives.postgresql.org/pgsql-hackers/2009-06/msg01281.php
http://archives.postgresql.org/pgsql-hackers/2009-07/msg01425.php

Tom, in particular, what do you think about implementing a general
purpose backend function similar to psql's \i (except without support
for \commands and :variables):

SELECT pg_execute_commands_from_file('path/ to/file.sql');

Your recent work about having a re-entrant parser should make it
possible to implement, by either "extending" or copy/pasting the
postgres.c:exec_simple_query, right?

(Difference is about not overriding current unnamed portal and maybe
forcing PortalRunMulti() usage, and that there's already a started
transaction (but start_xact_command() is a noop in this case))

On Jul 23, 2009, at 1:08 AM, Dimitri Fontaine wrote:

Easy answer for first version: don't allow user to install extension
in
another place than what we think will better suit him, and that's the
new schema pg_extension, which always lies just before pg_catalog in
the
search_path.

Well, I think that it's reasonable to allow an extension to be in any
schema, with the default being pg_extension, but all of the objects in
a single extension should assume that they're all in the same schema,
at least to start. I mean, I can see the need for secondary schemas
(or sub-schemas?) for encapsulation, but do we really need to go there
in the first rev?

Yes. I came up with the beginning of something (major version
dependant
additional install.sql files) but then you need to control ordering,
so
maybe pre and post install files with major version dependant
derivatives. "Over engineered" is certainly the comment I'll hear
about
it.

Yeah, so omit it for now, I say. Start with what's widely agreed-upon
and relatively simple. We can iterate this pony over time.

Best,

David

"David E. Wheeler" <david@kineticode.com> writes:

On Jul 23, 2009, at 1:08 AM, Dimitri Fontaine wrote:

Easy answer for first version: don't allow user to install extension in
another place than what we think will better suit him, and that's the
new schema pg_extension, which always lies just before pg_catalog in the
search_path.

Well, I think that it's reasonable to allow an extension to be in any
schema, with the default being pg_extension, but all of the objects in a
single extension should assume that they're all in the same schema, at
least to start. I mean, I can see the need for secondary schemas (or
sub-schemas?) for encapsulation, but do we really need to go there in the
first rev?

Well the problem with that is if for example I define foo() and bar()
functions in my extension, and the user also has a foo() function in his
own stuff (possibly lying in public, say).

Now if in my extenion in function bar() I call foo(), how do I make sure
I'm calling my extension's foo()?

--
dim

On Jul 23, 2009, at 2:11, Dimitri Fontaine <dfontaine@hi-media.com>
wrote:

Well the problem with that is if for example I define foo() and bar()
functions in my extension, and the user also has a foo() function in
his
own stuff (possibly lying in public, say).

Now if in my extenion in function bar() I call foo(), how do I make
sure
I'm calling my extension's foo()?

Part of the behavior of CREATE EXTENSION would be to automatically
schema-qualify references to objects in the extension. Or perhaps
extension authors would need to use some sort of variable for the
schema that would be properly resolved when CREATE EXTENSION installed
an extension.

Those are the first ideas that come to kind for me, anyway.

Best,

David

"David E. Wheeler" <david@kineticode.com> writes:

Part of the behavior of CREATE EXTENSION would be to automatically
schema-qualify references to objects in the extension. Or perhaps
extension authors would need to use some sort of variable for the schema
that would be properly resolved when CREATE EXTENSION installed an
extension.

What about embedded calls in, say, plperl functions.
--
dim

On Jul 23, 2009, at 8:09 AM, Dimitri Fontaine wrote:

What about embedded calls in, say, plperl functions.

Hence the variable suggestion. In fact, it might go back to the idea
of subschemas, perhaps the name of the extension should be part of the
qualifying? I dunno, I'm just kind of throwing ideas out there, but
it's starting to remind me of packages or classes. Inside a class, a
call to a method without an invocant automatically delegates to the
method in the class. That sort of thing. But I'm wary of over-
designing here, so I'm not sure what the right thing to do is, unless
it's to punt.

Best,

David