Re: Fixing insecure security definer functions

From: "Merlin Moncure" <mmoncure(at)gmail(dot)com>
To: "Tom Lane" <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: "Stephen Frost" <sfrost(at)snowman(dot)net>, "Peter Eisentraut" <peter_e(at)gmx(dot)net>, pgsql-hackers(at)postgresql(dot)org
Subject: Re: Fixing insecure security definer functions
Date: 2007-02-15 18:44:10
Message-ID: b42b73150702151044h59be9c78qebcb861459d11345@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On 2/13/07, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> I would suggest that the search path be added as an explicit parameter
> to CREATE FUNCTION, with a default of the current setting. The main
> reason for this is that it's going to be a real PITA for pg_dump if we
> don't allow an explicit specification.

yikes!

If you guys go through with forcing functions to attach to objects
when they are created, it will break almost every project I've ever
worked on :(. The schema/function combo fits into all kinds of de
facto partitioning strategies and organization methods.

I can understand invalidating plans when the search_path changes, though.

merlin

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2007-02-15 19:34:40 Re: "anyelement2" pseudotype
Previous Message Peter Eisentraut 2007-02-15 18:23:20 Re: Visual C++ function issues