Re: pg_execute_from_file review - Mailing list pgsql-hackers

From Tom Lane
Subject Re: pg_execute_from_file review
Date
Msg-id 29492.1291661012@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 7:19 AM, Tom Lane wrote:
>> On the whole I'd prefer not to have any substitution functionality
>> hard-wired into pg_execute_file either, though I can see the argument
>> that it's necessary for practical use.  Basically I'm concerned that
>> replace-equivalent behavior is not going to be satisfactory over the
>> long run: I think eventually we're going to need to think about
>> quoting/escaping behavior.  So I think it's a bad idea to expose the
>> assumption that it'll be done that way at the SQL level.

> +1

> I suspect that, for the purposes of the extensions patch, if CREATE EXTENSION could be modified to handle setting the
schemaitself, without requiring that the file have this magic line:
 

>    SET search_path = @extschema@;

> Then there would be no need for substitutions at all.

That's an interesting idea, but I'm not sure it's wise to design around
the assumption that we won't need substitutions ever.  What I was
thinking was that we should try to limit knowledge of the substitution
behavior to the extension definition files and the implementation of
CREATE EXTENSION itself.  I don't agree with exposing that information
at the SQL level.

(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.)
        regards, tom lane


pgsql-hackers by date:

Previous
From: Andrew Dunstan
Date:
Subject: Re: allow COPY routines to read arbitrary numbers of fields
Next
From: Tom Lane
Date:
Subject: Re: WIP patch for parallel pg_dump