On Fri, Aug 14, 2020 at 02:50:32PM -0400, Tom Lane wrote:
> However, in itself this can only fix references that are resolved during
> execution of the extension script. I don't see a good way to use the
> idea to make earthdistance's SQL functions fully secure. It won't do
> to write, say,
>
>
On 08/14/20 15:38, Tom Lane wrote:
> (3) If the SQL syntax is really just "WITH variable value [, ...]"
> then I'm afraid we're going to have a lot of parse-ambiguity problems
> with wedging full SET syntax into that. The ability for the righthand
There is precedent in the SET command for having
Chapman Flack writes:
> On 08/14/20 14:50, Tom Lane wrote:
>> SAVEPOINT s1;
>> SET LOCAL search_path = pg_catalog, pg_temp;
>> ... protected code here ...
>> RELEASE SAVEPOINT s1;
>> but this does not work because SET LOCAL persists to the end of the
>> outer transaction. Maybe we could invent a
On 08/14/20 14:50, Tom Lane wrote:
> SAVEPOINT s1;
> SET LOCAL search_path = pg_catalog, pg_temp;
> ... protected code here ...
> RELEASE SAVEPOINT s1;
>
> but this does not work because SET LOCAL persists to the end of the
> outer transaction. Maybe we could invent a vari
