Re: Extension Facility

From: "David E(dot) Wheeler" <david(at)kineticode(dot)com>
To: Dimitri Fontaine <dfontaine(at)hi-media(dot)com>
Cc: PostgreSQL-development Hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Extension Facility
Date: 2009-07-23 08:33:07
Message-ID: 600C202C-FBBA-4DBD-A238-E02EFF95387D@kineticode.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

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

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Dave Page 2009-07-23 08:52:03 Re: Upgrading our minimum required flex version for 8.5
Previous Message Jeremy Kerr 2009-07-23 08:21:18 [PATCH v4] [libpq] Try to avoid manually masking SIGPIPEs on every send()