Re: pg_execute_from_file review - Mailing list pgsql-hackers

From Tom Lane
Subject Re: pg_execute_from_file review
Date
Msg-id 26131.1291648749@sss.pgh.pa.us
Whole thread Raw
In response to Re: pg_execute_from_file review  (Dimitri Fontaine <dimitri@2ndQuadrant.fr>)
Responses Re: pg_execute_from_file review
List pgsql-hackers
Dimitri Fontaine <dimitri@2ndQuadrant.fr> writes:
> Tom Lane <tgl@sss.pgh.pa.us> writes:
>> Why is there a variadic replace() in this patch at all?  It seems just
>> about entirely unrelated to the stated purpose of the patch, as well
>> as being of dubious usefulness.

> It used not to being exposed at the SQL level, but just an internal loop
> in pg_execute_sql_file() when using the placeholders enabled
> variant. Then Itagaki wanted me to expose internals so that he basically
> can implement the logics in SQL directly.  It seems like we went a step
> too far in exposing this facility too.  Agreed in removing it at the SQL
> level.

Well, actually, my next question was going to be about removing the
variadic substitution in pg_execute_string too.  It's not apparent to me
that that function should have a rather lame substitution mechanism
hard-wired into it, when you can do the same thing with replace() in
front of it.

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


pgsql-hackers by date:

Previous
From: Merlin Moncure
Date:
Subject: Re: Suggesting a libpq addition
Next
From: Robert Haas
Date:
Subject: Re: Timeout for asynchronous replication Re: Timeout and wait-forever in sync rep