Re: PGXS: REGRESS_OPTS=--load-language=plpgsql - Mailing list pgsql-hackers

From Dimitri Fontaine
Subject Re: PGXS: REGRESS_OPTS=--load-language=plpgsql
Date
Msg-id m2pr413uma.fsf@hi-media.com
Whole thread Raw
In response to Re: PGXS: REGRESS_OPTS=--load-language=plpgsql  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: PGXS: REGRESS_OPTS=--load-language=plpgsql
List pgsql-hackers
Tom Lane <tgl@sss.pgh.pa.us> writes:
> Robert Haas <robertmhaas@gmail.com> writes:
>> I am still of the opinion that changing this was a bad idea for
>> exactly this reason.  We could perhaps ameliorate this problem by
>> implementing CREATE OR REPLACE for languages and emitting that
>> instead; then the command in the dump would be a noop.
>
> Not really going to help for existing dumps (nor future dumps made
> with pre-9.0 pg_dump versions).
>
> However, the case that is probably going to be the most pressing is
> pg_upgrade, which last I heard insists on no errors during the restore
> (and I think that's a good thing).  That uses the new version's pg_dump
> so a fix involving new syntax would cover it.

Not sure how helpful I'll be there, but I can't help placing the
extension's proposal again.

If we had extensions here, plpgsql would be a core maintained extension,
made available by CREATE EXTENSION in the database (which initdb would
do in templates), then have the language installed by means of issuing
an INSTALL EXTENSION command.

Now, what would help would be to have that support and have CREATE
LANGUAGE foo; be kept for compatibility only and issue INSTALL EXTENSION
foo; instead.

For those still with me, the choice to have plpgsql available by default
would then boil down to have initdb do the CREATE EXTENSION in the
template database, the database owner would still have to run the
INSTALL EXTENSION. So now --load-language is INSTALL EXTENSION and just
works as intended.

And older dumps are doing CREATE LANGUAGE plpgsql; which is converted to
INSTALL EXTENSION plpgsql;, which just works only because the extension
is made available by default.

So that if there's a CREATE LANGUAGE plpythonu, say, installing this
extension will only succeed when INSTALL EXTENSION plpythonu; has been
done either in the template1 database before creating the target
database, or in the target database itself.

So now we have "smart" success and failure modes falling from the
proposed model.

I'll dare not say "Hope This Helps" as I realize I failed to provide any
code for implementing the extension management proposal. But got back to
acceptable sleeping patterns and should be able to get back on the topic
later this year, unless (please) beaten to it :)

Regards,
-- 
dim


pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: PGXS: REGRESS_OPTS=--load-language=plpgsql
Next
From: Tom Lane
Date:
Subject: Re: PGXS: REGRESS_OPTS=--load-language=plpgsql