| From: | Cédric Villemain <cedric(dot)villemain(dot)debian(at)gmail(dot)com> |
|---|---|
| To: | "David E(dot) Wheeler" <david(at)justatheory(dot)com> |
| Cc: | Dimitri Fontaine <dimitri(at)2ndquadrant(dot)fr>, Robert Haas <robertmhaas(at)gmail(dot)com>, Daniel Farina <daniel(at)heroku(dot)com>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Heikki Linnakangas <heikki(dot)linnakangas(at)enterprisedb(dot)com>, pgsql-hackers(at)postgresql(dot)org |
| Subject: | Re: Inline Extension |
| Date: | 2012-01-27 10:19:01 |
| Message-ID: | CAF6yO=1ALJYv8o_2smxfP8zeAC332RSajBMpC9HxUPbo=B4aug@mail.gmail.com |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
>> So I'm going to prepare the next version of the patch with this design:
>>
>> - in catalog extension scripts for inline extension
>>
>> pg_extension_script(extoid, oldversion, version, script)
>>
>> oldversion is null when create extension is used
>> unless when using the create extension from 'unpackaged' form
>
> Would you keep all the migration scripts used over time to upgrade from one version to another?
yes, that is the idea. You then can play all the stack of SQL needed
to go from version "foo" to version "bar" (we don't care about version
format, here again).
>> - same as we have -t, add -e --extension to pg_dump so that you can
>> choose to dump only a given extension
>
> Also --exclude-extension?
It might be the default.
We need something to dump the content of
pg_catalog.pg_extension_script (or whatever table is going to contain
SQL code), per extension or all.
--
Cédric Villemain +33 (0)6 20 30 22 52
http://2ndQuadrant.fr/
PostgreSQL: Support 24x7 - Développement, Expertise et Formation
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Heikki Linnakangas | 2012-01-27 10:49:44 | Re: patch: ALTER TABLE IF EXISTS |
| Previous Message | Dean Rasheed | 2012-01-27 09:57:17 | Re: patch: ALTER TABLE IF EXISTS |