[ slightly more awake now ... ]
I wrote:
> Not sure it's that easy. I think DROP LANGUAGE can't assume that the
> language it's been told to drop is extension-ified. (Even if we do this
> for all the core ones, there are a dozen non-core ones that might not
> all get with the program right away.)
No, wait, that's nonsense. With what you're talking about, there would
never be a non-extension-ified language, because CREATE LANGUAGE would
force it to be attached to an extension. So maybe that problem isn't
so hard after all.
However, what *is* looking a bit hard is dump/restore behavior. By
default, pg_dump would proceed to dump an installed language as a CREATE
EXTENSION command, and that would fail on restore, especially if you
were trying to restore as non superuser. The behavior of
--binary-upgrade would be differently unpleasant: it would make the
extension, then try to CREATE LANGUAGE, and that would fail because the
extension name already exists. No doubt we could kluge those behaviors
too, but it's starting to look pretty messy.
On the whole I'd rather spend time trying to fix the real problem, which
is allowing CREATE EXTENSION to non-superusers. The general case of
that looks quite hard to me, but maybe we could get something that works
for the single case of an extension containing just a language.
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
