Re: [BUGS] *.sql contrib files contain unresolvable MODULE_PATHNAME - Mailing list pgsql-hackers

From Tom Lane
Subject Re: [BUGS] *.sql contrib files contain unresolvable MODULE_PATHNAME
Date
Msg-id 13733.1318432543@sss.pgh.pa.us
Whole thread Raw
In response to Re: [BUGS] *.sql contrib files contain unresolvable MODULE_PATHNAME  (Aidan Van Dyk <aidan@highrise.ca>)
Responses Re: [BUGS] *.sql contrib files contain unresolvable MODULE_PATHNAME
List pgsql-hackers
Aidan Van Dyk <aidan@highrise.ca> writes:
> On Wed, Oct 12, 2011 at 10:50 AM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
>> Hmm ...
>> \echo You should use CREATE EXTENSION foo to load this file!

> Decorate them with a marker like:
>    \extension <name> <version>
> And make the CREATE EXTENSION skip (or verify) it?
> It will make psql stop on the \extension command.

No, the point is not to stop or fail, it is to print out an unmistakable
user instruction.  Otherwise we'll still be getting "cube.sql failed to
load for me" bug reports.  So I think \echo is entirely sufficient,
and we should not rely on psql features that aren't there yet.  Ideally
this should do what we want even in older psql releases.  \echo has been
there at least since 7.0.

It strikes me that we could get rid of the error message clutter
I worried about before if we coded like this:
/* contrib/foo--1.0.sql */
\echo Use "CREATE EXTENSION foo" to load this file. \quit
... SQL commands here ...

The forced \quit is a bit unfriendly maybe but it will get the job done.
And again, this isn't making any assumptions about which psql version
you're using.
        regards, tom lane


pgsql-hackers by date:

Previous
From: Aidan Van Dyk
Date:
Subject: Re: [BUGS] *.sql contrib files contain unresolvable MODULE_PATHNAME
Next
From: Tom Lane
Date:
Subject: Re: COUNT(*) and index-only scans