From: | Thomas Kellerer <spam_eater(at)gmx(dot)net> |
---|---|
To: | pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: proposal: integration bloat tables (indexes) to core |
Date: | 2016-06-16 20:42:21 |
Message-ID: | 1466109741983-5908273.post@n5.nabble.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Tom Lane-2 wrote
> The problem with an extension is: when we make a core change that breaks
> one of these views, which we will, how can you pg_upgrade a database
> with the extension installed? There's no provision for upgrading an
> extension concurrently with the core upgrade. Maybe there should be,
> but I'm unclear how we could make that work.
>
> At the same time, I'm pretty suspicious of putting stuff like this in
> core, because the expectations for cross-version compatibility go up
> by orders of magnitude as soon as we do that.
Why not provide a "SQL" or "Admin Scripts" directory as part of the
installation that contains community "recommended" scripts for things like
that? As those aren't extensions or somehow part of the data directory they
don't need to be migrated and pg_upgrade does not need to take care of that.
When installing a new version, the new scripts that work with the new
version are installed automatically but will not overwrite the old version's
scripts as the new version typically is stored in a different directory.
--
View this message in context: http://postgresql.nabble.com/proposal-integration-bloat-tables-indexes-to-core-tp5907511p5908273.html
Sent from the PostgreSQL - hackers mailing list archive at Nabble.com.
From | Date | Subject | |
---|---|---|---|
Next Message | Vik Fearing | 2016-06-16 20:51:33 | Re: pgsql: Update pg_stat_statements extension for parallel query. |
Previous Message | Tom Lane | 2016-06-16 20:31:14 | Parallelized polymorphic aggs, and aggtype vs aggoutputtype |