Re: pg_execute_from_file review - Mailing list pgsql-hackers

From Tom Lane
Subject Re: pg_execute_from_file review
Date
Msg-id 29958.1291662768@sss.pgh.pa.us
Whole thread Raw
In response to Re: pg_execute_from_file review  ("David E. Wheeler" <david@kineticode.com>)
Responses Re: pg_execute_from_file review  ("David E. Wheeler" <david@kineticode.com>)
List pgsql-hackers
"David E. Wheeler" <david@kineticode.com> writes:
> On Dec 6, 2010, at 10:43 AM, Tom Lane wrote:
>> (On the other hand, if we *could* avoid using any explicit
>> substitutions, it would certainly ease testing of extension files no?
>> They'd be sourceable into psql then.)

> Yes. And extension authors would not have to remember to include the magic line (which at any rate would break
extensionsfor earlier versions of PostgreSQL).
 

Well, I don't put any stock in the idea that it's important for existing
module .sql files to be usable as-is as extension definition files.  If
it happens to fall out that way, fine, but we shouldn't give up anything
else to get that.  Letting extension files be directly sourceable in
psql is probably worth a bit more, but I'm not sure how much.  The
argument that forgetting to include a magic source_path command would
make CREATE EXTENSION behave surprisingly seems to have a good deal of
merit though, certainly enough to justify having CREATE EXTENSION take
care of that internally if at all possible.

The real question in my mind is whether there are any other known or
foreseeable cases where we would need to have substitution capability
and there's not another good way to handle it.  I haven't been paying
real close attention to the threads about this patch --- do we have any
specific use-cases in mind for substitution, besides this one?
        regards, tom lane


pgsql-hackers by date:

Previous
From: "Kevin Grittner"
Date:
Subject: Re: WIP patch for parallel pg_dump
Next
From: "David E. Wheeler"
Date:
Subject: Re: pg_execute_from_file review