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