Re: search_path vs extensions

From: "David E(dot) Wheeler" <david(at)kineticode(dot)com>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: Greg Stark <stark(at)enterprisedb(dot)com>, Robert Haas <robertmhaas(at)gmail(dot)com>, Dimitri Fontaine <dfontaine(at)hi-media(dot)com>, Andrew Gierth <andrew(at)tao11(dot)riddles(dot)org(dot)uk>, PostgreSQL Hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: search_path vs extensions
Date: 2009-05-28 21:26:55
Message-ID: A0F213CC-4839-44A3-8D3B-A13FEA6B2FF1@kineticode.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On May 28, 2009, at 12:33 PM, Tom Lane wrote:

> Greg Stark <stark(at)enterprisedb(dot)com> writes:
>> Is that really a complete answer? How do we deal with upgrading an
>> extension to a more recent version? What happens to objects in the
>> database which depend on objects from the extension?
>
> Well, if it's only a code change then you install a newer version of
> the
> .so and you're done. If the extension upgrade requires altering any
> SQL-level properties of the module's objects then I'd expect the
> extension author to provide a SQL script to do that.

It would be convenient for me a module/extension author not to have to
write upgrade scripts for every version of my module/extension.

> Obviously there is value in being able to do things like add new
> objects
> to an existing module, but we hashed out the mechanisms for that long
> ago. IIRC the proposed syntax was along the lines of
>
> CREATE EXTENSION foo;
>
> BEGIN EXTENSION foo;
>
> ... anything created here is automatically tagged as belonging
> to foo ...
>
> END EXTENSION foo;

I like it.

Best,

David

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Andy Colson 2009-05-28 21:27:38 Re: sun blade 1000 donation
Previous Message Bruce Momjian 2009-05-28 21:26:20 Re: pg_migrator and an 8.3-compatible tsvector data type