On Tue, 2013-12-03 at 10:08 +0200, Heikki Linnakangas wrote: > Another perspective is that that's already a situation we'd rather not > have. Let's not make it worse by introducing a third way to install an > extension, which again requires the extension author to package the > extension differently.
+1. > Why? The external tool can pick the extension in its current form from > PGXN, and install it via libpq. The tool might have to jump through some > hoops to do it, and we might need some new backend functionality to > support it, but I don't see why the extension author needs to do anything. Ideally, it would end up the same whether it was installed by either method -- the same entries in pg_extension, etc. I assume that's what you mean by "new backend functionality". This sounds like Inline Extensions to me, which was previously proposed. If I recall, that proposal trailed off because of issues with dump/reload. If you dump the contents of the extension, it's not really an extension; but if you don't, then the administrator can't back up the database (because he might not have all of the extension templates for the extensions installed). That's when the idea appeared for extension templates stored in the catalog, so that the administrator would always have all of the necessary templates present. A few interesting messages I found: http://www.postgresql.org/message-id/CA +TgmobJ-yCHt_utgJJL9WiiPssUAJWFd=3=ulrob9nhbpc...@mail.gmail.com http://www.postgresql.org/message-id/CA +tgmoztujw7beyzf1dzdcrbg2djcvtyageychx8d52oe1g...@mail.gmail.com http://www.postgresql.org/message-id/CA +tgmoa_0d6ef8upc03qx0unhjfzozeosno_ofucf5jgw+8...@mail.gmail.com http://www.postgresql.org/message-id/18054.1354751...@sss.pgh.pa.us (+Robert,Tom because I am referencing their comments) Regards, Jeff Davis -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers