Skip site navigation (1) Skip section navigation (2)

Re: Extension Facility

From: Dimitri Fontaine <dfontaine(at)hi-media(dot)com>
To: "David E(dot) Wheeler" <david(at)kineticode(dot)com>
Cc: PostgreSQL-development Hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Extension Facility
Date: 2009-07-23 08:08:34
Message-ID: (view raw, whole thread or download thread mbox)
Lists: pgsql-hackers

"David E. Wheeler" <david(at)kineticode(dot)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 ...

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

>> - 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


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.

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))

In response to


pgsql-hackers by date

Next:From: Jeremy KerrDate: 2009-07-23 08:21:18
Subject: [PATCH v4] [libpq] Try to avoid manually masking SIGPIPEs on everysend()
Previous:From: Itagaki TakahiroDate: 2009-07-23 07:56:48
Subject: trace hooks (for 2nd commitfest)

Privacy Policy | About PostgreSQL
Copyright © 1996-2017 The PostgreSQL Global Development Group