Re: I propose killing PL/Tcl's "modules" infrastructure

From: Andrew Dunstan <andrew(dot)dunstan(at)2ndquadrant(dot)com>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: pgsql-hackers(at)postgresql(dot)org, Jan Wieck <jan(at)wi3ck(dot)info>
Subject: Re: I propose killing PL/Tcl's "modules" infrastructure
Date: 2017-02-25 20:11:12
Message-ID: 45faa542-212a-5225-2b62-c80a8df2d0fd@2ndQuadrant.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On 02/25/2017 02:21 PM, Tom Lane wrote:
> Andrew Dunstan <andrew(dot)dunstan(at)2ndquadrant(dot)com> writes:
>> On 02/25/2017 01:44 PM, Tom Lane wrote:
>>> Yeah, the only part that's even a bit hard to replicate in userland is
>>> initializing the autoloading mechanism in each session. It would be
>>> cleaner to provide a feature similar to what you describe that could
>>> be used for that purpose as well as others. However, where does the
>>> "parameterless function" come from? Is it a regular PLv8 (or for this
>>> purpose PL/Tcl) function expected to be present in pg_proc?
>> Yes, it's a regular PLv8 function.
> OK ... how do you handle security considerations? Can the GUC be set
> at any time/by anybody? What determines whether you have permissions
> to call the particular function?
>
>

It can be set by anyone, IIRC. Maybe it should be SUSET only, I don't
know. It's executed as the session owner. Execute permission on the
function are determined the same way as for any function. It's an
ordinary function call. The only difference is in how the call gets
triggered.

cheers

andrew

--
Andrew Dunstan https://www.2ndQuadrant.com
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Simon Riggs 2017-02-25 20:30:16 Re: dropping partitioned tables without CASCADE
Previous Message Simon Riggs 2017-02-25 19:43:51 Re: Proposal for changes to recovery.conf API