Re: Dumping an Extension's Script - Mailing list pgsql-hackers

On Thu, Nov 15, 2012 at 3:09 PM, Dimitri Fontaine
<dimitri@2ndquadrant.fr> wrote:
> Robert Haas <robertmhaas@gmail.com> writes:
>>> Please find attached to this email an RFC patch implementing the basics
>>> of the pg_dump --extension-script option. After much discussion around
>>> the concept of an inline extension, we decided last year that a good
>>> first step would be pg_dump support for an extension's script.
>>
>> Do you have a link to the original thread?  I have to confess I don't
>> remember what the purpose of this was and, heh heh, there are no
>> documentation changes in the patch itself either.
>
> My notes include those links to the original thread:
>
>   http://archives.postgresql.org/message-id/3157.1327298440@sss.pgh.pa.us
>   http://archives.postgresql.org/pgsql-hackers/2012-01/msg01311.php
>   https://commitfest.postgresql.org/action/patch_view?id=746
>
> I could of course work on documenting the changes prior to the
> reviewing, the thing is that I've been taking a different implementation
> route towards the pg_dump --extension-script idea we talked about, that
> I think is much simpler than anything else.
>
> So I'd like to know if that approach is deemed acceptable by the
> Guardians Of The Code before expanding any more hour on this…
>
> It basically boils down to this hunk in dumpExtension():
>
>   output CREATE EXTENSION x WITH … AS $x$
>
>    /*
>     * Have another archive for this extension: this allows us to simply
>     * walk the extension's dependencies and use the existing pg_dump code
>     * to get the object create statement to be added in the script.
>     *
>     */
>    eout = CreateArchive(NULL, archNull, 0, archModeAppend);
>
>    EH = (ArchiveHandle *) eout;
>
>    /* grab existing connection and remote version information */
>    EH->connection = ((ArchiveHandle *)fout)->connection;
>    eout->remoteVersion = fout->remoteVersion;
>
>    /* dump all objects for this extension, that have been sorted out in
>     * the right order following dependencies etc */
>    ...
>
>    /* restore the eout Archive into the local buffer */
>    for (te = EH->toc->next; te != EH->toc; te = te->next)
>    {
>            if (strlen(te->defn) > 0)
>                    appendPQExpBuffer(q, "%s", te->defn);
>    }
>    CloseArchive(eout);
>
>   output $x$;
>
> What do you think?

That approach seems likely to break things for the hoped-for parallel
pg_dump feature, though I'm not sure exactly in what way.

Beyond that, I think much of the appeal of the extension feature is
that it dumps as "CREATE EXTENSION hstore;" and nothing more.  That
allows you to migrate a dump between systems with different but
compatible versions of the hstore and have things work as intended.
I'm not opposed to the idea of being able to make extensions without
files on disk work ... but I consider it a niche use case; the
behavior we have right now works well for me and hopefully for others
most of the time.

--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company