Re: Facility for detecting insecure object naming

Поиск
Список
Период
Сортировка
От Robert Haas
Тема Re: Facility for detecting insecure object naming
Дата
Msg-id CA+TgmoZbNXP_=ExtzZsmDX34FvWrXTxW_QM0f1sx1=OVt97ciA@mail.gmail.com
обсуждение исходный текст
Ответ на Re: Facility for detecting insecure object naming  (Bruce Momjian <bruce@momjian.us>)
Ответы Re: Facility for detecting insecure object naming
Список pgsql-hackers
On Wed, Aug 15, 2018 at 3:17 PM, Bruce Momjian <bruce@momjian.us> wrote:
> On Wed, Aug 15, 2018 at 11:05:06AM -0400, Robert Haas wrote:
>> On Tue, Aug 14, 2018 at 4:42 PM, Bruce Momjian <bruce@momjian.us> wrote:
>> > So you are saying PG functions should lock down their search path at
>> > function definition time, and use that for all function invocations?
>>
>> Yes, mostly.  I don't think we can just change the existing behavior;
>> it would break a catastrophic amount of stuff.  But we could add an
>> optional feature that does this, and encourage people to use it, much
>> the way Perl continues to support "local" even though "my" has been a
>> best practice for several decades.
>
> So each function defines its search_path, and each function you call sets
> its own search_path, basically?  That is what you mean by lexical scope?
> I think if this approach was fully secure, it would get more traction.

By lexical scope, I mean a search_path that applies only to the SQL
queries that textually appear within that function definition, not
code that they call indirectly.  The SET clause attached to a function
uses dynamic scope.  See
https://en.wikipedia.org/wiki/Scope_(computer_science)#Lexical_scope_vs._dynamic_scope

-- 
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company


В списке pgsql-hackers по дате отправления:

Предыдущее
От: Robert Haas
Дата:
Сообщение: Re: Add a semicolon to query related to search_path
Следующее
От: Peter Geoghegan
Дата:
Сообщение: Re: Index Skip Scan